Re: [boost] boost::exception questions

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-10-01 05:01:42

Emil Dotchevski wrote:
>> <snip>
>> I see. This feature is most valuable. However, so is Tom's suggestion
>> and I don't think both are mutually exclusive (that is if we let go of
>> using the template-id 'error_info' for the latter):
>>
>>      typedef boost::custom_exception<tag::
>>          errno,tag::filename,tag::size> file_error;
> 
> Consider this code:
> 
> void read_file( char const * filename )
> {
>     something_unrelated();
>     ....
>     if( file_failure )
>         throw file_error() << error_info<tag_filename>(filename);
> }
> 
> If I understand correctly, you are concerned with making sure all
> file_error exceptions pack a file_name.

No, not my point. It's about increasing the expressiveness of client 
code: It provides means for a user to express: "I'm going to throw a 
bunch of exceptions (starting) with common attributes. Please give me a 
brief way to create them, so error reporting doesn't obscure my code."

It also allows to easily port "traditional" exception classes to 
boost::exception.

Further it would allow to allocate the attributes of a custom_exception 
in one shot.

> But what if "something_unrelated" throws? Isn't the filename known to
> our function relevant to that other failure too? 

Since it was an abstract example it sure depends on the case.

> It sure is, despite
> that we have no idea what exceptions "something_unrelated" could
> throw.
> 
> So, I'd write that function like this:
> 
> void read_file( char const * filename )
> {
>     try
>     {
>         something_unrelated();
>         ....
>         if( file_failure )
>             throw file_error();
>     }
>     catch( boost::exception & x )
>     {
>         x << error_info<tag_filename>(filename);
>         throw;
>     }
> }
> 
> How would your custom_exception idea fit in this framework?

So now you're bringing up a different use case. Of course you're still 
free to use this pattern at any factorization that is reasonable e.g. 
providing a 'file_error' base class and an 'io_error' custom_exception 
that always adds 'errno' and an enum describing the failed operation.

Regards,
Tobias Schwinger
- Review Manager -