On Mon, Jul 21, 2008 at 9:55 AM, vicente.botet
If I understood, the MSVC-specific code allows the user to get the current exception without throwing the exception with boost::enable_current_exception(). What is the advantage if we can not profit of this mechanism with other compilers?
Adding support for MSVC doesn't prevent or make it more difficult to add similar support for GCC and other compilers. Antony's implementation is a good example to follow, IMO.
A few months ago I proposed an intrusive way allowing the user to define which exceptions where wrapped by boost::exception_ptr. IMHO, the exception_ptr emulation (without language support) to transport exceptions between threads is not of real use if the user can not configurate the exceptions that can be thrown by 3pp as the Exception library do already for the STL exceptions.
I don't consider what the exception library does for STL exceptions very valuable. It can even be argued that it's fundamentally flawed in that it erases the actual exception type in case someone throws (for example) an exception that derives std::logic_error. Still, it is a reasonable workaround for the lack of language support. As last resort, you get an object of type boost::unknown_exception. This at least guarantees that no exception gets ignored.
For recall, my proposal was the following: The exception library defines a macro such as:
#define BOOST_EXCEPTION_CATCH_RETURN(EXCP) \ catch( EXCP & e ) { \ return exception_detail::current_exception_unknown_boost_exception(e); \ }
The current_exception function has a USER_SLOT used us follows
inline exception_ptr current_exception() { try { throw; } catch( exception_detail::cloning_base & e ) { exception_detail::clone_base const * c = e.clone(); BOOST_ASSERT(c!=0); return exception_ptr(c); } catch( std::invalid_argument & e ) { return exception_detail::current_exception_std_exception(e); } // ... as before #ifdef BOOST_EXCEPTION_USER_SLOT #include BOOST_EXCEPTION_USER_SLOT #endif catch( ... ) { return exception_detail::current_exception_unknown_exception(); }
I don't see the benefit of using a macro to inject this functionality into Boost. Instead, you could do something along the lines of (note, this won't work for abstract foo or bar): try { try { //call functions that throw without using boost::enable_current_exception } catch( foo & e ) { throw boost::enable_current_exception(e); } catch( bar & e ) { throw boost::enable_current_exception(e); } } catch( ... ) { boost::exception_ptr ep=boost::current_exception(); ... } Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode