On Wed, May 13, 2009 at 10:18 AM, Adam Badura <abadura@o2.pl> 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.ht... for the updated documentation. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode