Support for asynchronous exception handling is also very important, but is missing from Exception. Can exception::pimpl remember the user exception type (CRTP), for the sake of clone/raise?
Cloning exceptions is out of the scope of Boost Exception. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html.
The need to preregister tag types is slightly annoying. The need to specify the data-type with the tag is especially annoying.
Why not use accompanying text as a key to retrieve values?
The rationale for the tag type registration is to provide compile-time type safety, which is also why the value type is required at the time of the registration. If there is a consensus that compile-time type safety is less important than the convenience of string-based identification, the interface for adding data to exceptions can be changed: .... catch( boost::exception & x ) { x.add<int>("errno"); throw; } Retrieval would then look like this: .... catch( boost::exception & x ) { if( int const * ec = x.get<int>("errno") ) { //ec points the int at "errno", or... } else { //...is null if x has no such int. } } In my opinion, compile-time type safety is especially important in the case of boost::exception. It is true that type inconsistencies are not the only thing that can go wrong, but the error handling paths of any program are the hardest to test; catching any error-handling bug at compile time is very valuable.
try { int value=5; throw exception() << "Something went wrong. value=" << value; }
This approach is inappropriate in general, because the actual formatting of the text is locale-specific and is best done when handling the exception, not when throwing. Emil Dotchevski