Emil Dotchevski wrote:
2. Cloning of the exception. When I catch exception thrown in a worker thread I create clone of it and throw it in the thread which requested the task to be executed in separate thread. It looks like:
struct my_exc : public boost::exception { virtual my_exc* clone() { return new *this; } };
I'd created common abstract subclass because of it, perhaps it would make sense somehow to support the feature.
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? boost::exception can't be a replacement for (modified, according to the paper referenced above) std::exception without at least providing the abstract member functions. 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?
2. Shouldn't all inheritance of "boost::exception," especially via "enable_error_info," be of the virtual kind?
This is another thing I didn't pay much attention to in the documentation, because deriving boost::exception is the same as deriving std::exception.
As for enable_error_info, I am planning to change it to not inject boost::exception as a base if it already is a base. This would allow enable_error_info to be used in boost::throw_exception regardless of whether a particular exception type derives from boost::exception, or not. This nullifies the concerns whether enable_error_info uses virtual or non-virtual inheritance.
Sounds like a good plan to me. 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)? Regards, Tobias Schwinger - Review Manager -