
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. And of course the whole idea that to gain benefit of a library one has to change the code of all the other libraries that the application might use is a big problem for me. The fact that the author doesn't think this is a problem is a very strong suggestion to me that I'd find the library problematic to actually use. And this is even before I've really even looked at it. I've more than a little skeptical. And I believe that a solution could have been crafted to avoid the issues that I've raised but that Emil doesn't agree that these concerns are legimate. I know steve doesn't agree with me on this either. So now I would have to provide a counter example which means basically re-doing the original work in the right way as I see it.
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. Robert Ramey