Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at