Re: [boost] [review] Exception

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-10-22 16:28:31

Emil Dotchevski wrote:
>>>> I see the http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html
>>>> now but it doesn't help me here and now, I think.
>>> I believe that cloning exceptions is outside the scope of Boost Exception.
>> Are you sure?
> 
> In n2179 exception cloning and re-throwing is decoupled from any
> particular exception type.
> 
>> Further, putting an exception that supports cloning through
>> 'enable_error_info' currently gives us an exception that only clones a
>> subobject, while it's actually quite inviting to have the most derived
>> (, unspecified) exception class implement clone/rethrow stuff, isn't it?
> 
> enable_error_info can not clone an exception; that is, you can not
> catch a (base) type, and then throw a copy of it using
> enable_error_info to inject boost::exception as a base.

Not quite what I was talking about.

You instantiate 'detail::unspecified_exception_type<...>' (or so), which
could very well implement cloning as all types are known at this point.

>> BTW. what do you think about making the other (, inherited) exception
>> accessible through the interface of boost::exception (that is, using a
>> reserved tag and having 'what' call inherited 'what' for formatting)?
> 
> To clarify what you mean (correct me if I'm wrong): you throw an
> exception using enable_error_info, for example:
> 
> throw boost::enable_error_info(std::bad_alloc());
> 
> As per enable_error_info specification, you can catch this exception
> as std::bad_alloc, or as boost::exception, and you want to be able to
> get to the bad_alloc sub-object from a boost::exception pointer.

I want to catch 'boost::exception' and have 'bad_alloc' as a first class 
element within it.

> I think that there is no need for this functionality as you can simply
> use dynamic_cast (though the typical use of dynamic_cast in this case
> would be to get to the boost::exception sub-object after you catch a
> bad_alloc.)

Yes, but it's very irregular and sorta ugly as we're dealing with two 
independent (but munged-together) objects that both carry incomplete 
information.

> But I agree that it's a good idea to override what() in the type
> enable_error_info throws.

No, it seems to be a misunderstanding, again. And frankly it's not a 
good idea at all, IMO. Personally I'm not even convinced that 
'enable_error_info' is a good idea to begin with...

Regards,
Tobias