On Wed, May 13, 2009 at 11:58 PM, Adam Badura <abadura@o2.pl> wrote:
The explicit handling of std exceptions in boost::current_exception is a fallback, mostly to deal with exceptions emitted by the standard library itself. For user-defined types (such as null_pointer) boost::enable_current_exception should be used at throw time.
Note:
- This slicing of standard exceptions -- while not ideal -- is still better than getting an exception_ptr that refers to boost::unknown_exception.
What about providing an interface:
class ClonableException { public: virtual ~ClonableException() {}
virtual ClonableException* clone() const = 0; };
The library already contains a similar undocumented type.
The cloning code would query for this interface first and use it (the exception class made by enable_current_exception would inherit from this interface as well) to make a copy. This way user would be able to clone exactly his exceptions.
That's how it works currently. The only difference is that instead of documenting the interface that needs to be implemented for current_exception to work, the burden of implementing it is shifted to the enable_current_exception function.
Note that this would also solved problem in enable_current_exception with virtual base classes that are not default constructible - mentioned in earlier thread.
It would, but I don't see a reason to use exception types without default constructors with Boost Exception. So, in my mind this problem is only theoretical. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode