Re: [boost] [exception] current_exception mishandling standardexceptions

Subject: Re: [boost] [exception] current_exception mishandling standardexceptions
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-05-14 14:18:23

On Wed, May 13, 2009 at 11:58 PM, Adam Badura <abadura_at_[hidden]> 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