Question

When I use boost::copy_exception to copy an exception to an exception_ptr, I lose type information. Take a look at the following code:

try {
    throw std::runtime_error("something");
} catch (exception& e) {
    ptr = boost::copy_exception(e);
}
if (ptr) {
    try {
        boost::rethrow_exception(ptr);
    } catch (std::exception& e) {
        cout << e.what() << endl;
        cout << boost::diagnostic_information(e) << endl;
    }
}

From this, I get the following output:

N5boost16exception_detail10clone_implISt9exceptionEE
Dynamic exception type: boost::exception_detail::clone_impl<std::exception>
std::exception::what: N5boost16exception_detail10clone_implISt9exceptionEE

So basically boost::copy_exception statically copied the argument it got.

This problem is solved if I throw my exception with boost::enable_current_exception instead, like this.

try {
    throw boost::enable_current_exception(std::runtime_error("something"));
} catch (...) {
    ptr = boost::current_exception();
}
if (ptr) {
    try {
        boost::rethrow_exception(ptr);
    } catch (std::exception& e) {
        cout << e.what() << endl;
        cout << boost::diagnostic_information(e) << endl;
    }
}

The problem with this is that sometimes the exceptions are thrown by a library that does not use boost::enable_current_exception. In this case, is there any way to put the exception into an exception_ptr apart from catching each kind of possible exception one by one and use boost::copy_exception on each one?

Answer 1

This is by design, and your analysis is correct: the static type is used, not the dynamic type. In fact, to avoid this surprise, boost::copy_exception became std::make_exception_ptr during the process that led to C++11. That way, it’s clearer that current_exception (whether the Boost version or the C++11 one) is the correct thing to use to correctly capture, well, the current exception. I highly recommend using BOOST_THROW_EXCEPTION, or at least boost::throw_exception, when it comes to using Boost.Exception-enabled exceptions in your code.

When it comes to third-party code, there is no solution other than the one you already mentioned, or some other moral equivalent (like dynamic_cast-ing to the different leaf classes that make up the exception type hierarchy or hierarchies, or typeid abuse).

In this respect exception handling is the same as working with one or more hierarchy of polymorphic types, and the operation you’re attempting in this case is a virtual copy, also known as cloning: either your code is intrusively designed to support that (as is the case when using e.g. BOOST_THROW_EXCEPTION(e); instead of throw e;), or you’re going to painfully walk the inheritance tree. Note that you can at least refactor that pain into just one site, such that you’d end up with e.g.

try {
    third_party_api();
} catch(...) {
    ptr = catch_exceptions_from_api();
}