on Sun Jun 24 2012, "Robert Ramey" <ramey-AT-rrsd.com> 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.
IMO it is unreasonable to expect "BOOST_THROW_EXCEPTION(e)" to work better in this regard than "throw e" does. As I wrote above, they have the exact same issue.
It's totally non-intuitive and a trap for users.
IMO it's totally intuitive for BOOST_THROW_EXCEPTION to follow the pattern set by "throw." Of course it would be nice if the library facility could be somehow more forgiving of ignorance and misuse than "throw" is, but, well, it can't.
There is no mention of this in the documentation.
With all due respect, from the foregoing discussion it is plain that there are a few fairly basic things about the behavior of C++ exceptions that you didn't understand, and that lack of understanding has colored your expectations of the library. You also expected "throw e" to be non-slicing. It might be very nice if the library documentation included a tutorial on these issues, but it's unreasonable to treat it as a defect in the library.
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.
I agree absolutely. The C++ language should make it more natural and MUCH less intrusive to do this stuff. There's always a balancing act when you have to decide whether to proceed with implementing something that cuts across the grain of the language. Sometimes it's not worth the cost. As these sorts of things go, this one has a fairly low cost, but it's not free.
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.
It's understandable that you'd take issue with the author's attitude toward your objections. However, I think part of the problem, for which you might consider taking responsibility, is that your reaction to the issue has been somewhat... intemperate and overbroad. That tends to make other people dismissive ("he *can't* be serious!"), and with that, any legitimate concerns tend to get swept aside.
And this is even before I've really even looked at it. I've more than a little skeptical.
Quite clearly.
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.
Wait; there are two separate things: 1. Are your concerns legitimate? 2. Is there a design that avoids these issues? I've seen lots of argument about #2, but not much about #1. I haven't read everything that Emil has posted, but Steven in particular has stuck closely to the technical stuff (#2). Re: #2, I don't see how there can be a substantially better design for this facility either, at least with C++ as it exists today.
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.
Unfortunately, yes. There's no other way to support your claim about #2.
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.
It's trivial: boost::throw_exception(1) you detect it by setting BOOST_NO_EXCEPTIONS, which causes the code to stop compiling. A reasonable rewrite of the original boost::throw_exception that does this detection without adding any new functionality might be: #ifdef BOOST_NO_EXCEPTIONS void throw_exception( std::exception const & e ); // user defined #else template<class E> void throw_exception(E const & e){ std::exception const& must_be_a_std_exception = e; // <=== NEW throw(e); } #endif Arguably it would have gone more smoothly for Emil had he done this, then waited a while (a whole release cycle?), and then implemented his changes. Then nobody would have been able to complain that Boost.Exception broke their code. -- Dave Abrahams BoostPro Computing http://www.boostpro.com