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
Yes, but it's very irregular and sorta ugly as we're dealing with two
independent (but munged-together) objects that both carry incomplete
> 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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk