Re: [boost] [exception] current_exception mishandling standard exceptions

Subject: Re: [boost] [exception] current_exception mishandling standard exceptions
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-05-13 20:39:44

On Wed, May 13, 2009 at 10:18 AM, Adam Badura <abadura_at_[hidden]> wrote:
>   It seems that current_exception mishandles standard exceptions. I noted
> two problems:
>
> 1)
>
>   Some standard exceptions are not handled at all. This includes
> std::runtime_error and its derived (std::overflow_error, std::range_error,
> std::underflow_error), std::domain_error (handled by general
> std::logic_error), std::length_error (handled by general std::logic_error)
> and std::ios_base::failure (handled by general std::exception).
>   Why is it so?

Dunno. :) I've added them now.

> 2)
>
>   Non-standard exceptions derived from standard exceptions are sliced by
> current_exception. It detects those types by throwing and caching and thus
> will catch also derived types (like null_pointer : public
> std::invalid_argument). But during construction of internal structures the
> standard exception type is used and thus copy construction slices the
> original exception object.
>   If typeid was used instead of throwing/catching (or dynamic_cast) to
> detect the type current_exception could at least detect that is will slice
> the original object and use a different type so it would not pretend
> everything is OK.

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.

- The caller of boost::current_exception should reasonably deal with
the possibility of getting exception_ptr that refers to a type the
program did not actually throw, such as boost::unknown_exception or
(unlikely) std::bad_alloc.

- Even if you get a boost::unknown_exception, its boost::exception
subobject will have all the data contained in the boost::exception
subojbect of the original exception object (assuming of course that
the original exception object is of type that derives from
boost::exception.)

- Finally, with trunk revision 52981 whenever current_exception fails
to properly clone the exception object, it attempts to store the
type_info of the original exception object as error_info. See
http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception.html
for the updated documentation.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode