on Sat Jun 23 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
on Sat Jun 23 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
If you really like boost::exception your code when you eventually can eventually rethrow
catch (std::exception & e){ // not additon of & BOOST_THROW_EXCEPTION(e) }
IIUC, even if you change it to catch by reference, as you should, and even if std::exception weren't an abstract base class, which it is, that approach will slice the caught exception and lose all the information thrown with it. BOOST_EXCEPTION_THROW_EXCEPTION needs to copy the exception object into this type it builds with multiple inheritance from boost::exception, and it needs to do this with full knowledge of the static type of the exception being thrown.
wow I overlooked this.
So in our case, if e was reference to an instance of a boost::archive::archive_exception object which holds all the interesting data, this information would be thrown away along with the actual type of the exception? That's terrible.
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. 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. -- Dave Abrahams BoostPro Computing http://www.boostpro.com