Boost logo

Boost :

From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-10-19 13:31:30


> >> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk