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