On 24/06/2012 2:40, Robert Ramey wrote:
Dave Abrahams wrote:
on Sat Jun 23 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Like some other things we've discussed, that's essentially a C++ language feature. You couldn't do a plain "throw e" either, without causing the slice. The only way to propagate the contents of e is "throw;", which is obviously incapable of enhancing the thrown exception in any way.
The the more you pick at Emil's design and the more I check your arguments, the more impressed I am with the care he took.
My reaction is just the opposite
even little things are a problem, The first thing I looked at was the documentation of BOOST_THROW_EXCEPTION(e).
If this is invoked at the exception site it works. If it is invoked anywhere else - like a rethrow it doesn't. It's totally non-intuitive and a trap for users. There is no mention of this in the documentation.
This is the nature of C++ exceptions, it is no different for simply `throw e;`. It may be non-intuitive for those not versed in C++ exceptions (they are far more complex than they appear), and its certainly a trap for users but such trap comes from the standard and not from Boost.Exception.
I may be misunderstanding, but IIUC, the "problem" that he "fixed" was that his change caused already-unsupported misuses of boost::throw_exception to stop compiling. It's arguable that those misuses *should* be flagged with compiler errors.
the original boost::throw_exception was defined as:
#ifdef BOOST_NO_EXCEPTIONS void throw_exception( std::exception const & e ); // user defined #else template<class E> void throw_exception(E const & e){ throw(e); } #endif
it's hard to see how one could even define "misuse" of this - much less detect it.
As it was previously stated, the misuses of boost:throw_exception where those that didn't pass an exception derived from std::exception. They would fail when BOOST_NO_EXCEPTIONS was defined, they fail all the time now. Agustín K-ballo Bergé.-