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. enable_error_info can only be used before the exception object is passed to the implementation by a throw. At that time the exception object can be copied by the copy constructor.
<snip>
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 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.) But I agree that it's a good idea to override what() in the type enable_error_info throws. Thanks, Emil Dotchevski