Re: [boost] [exception][policy]

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-27 19:36:00

on Wed Aug 27 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:

> David Abrahams:
>
>> So IIUC, your intention was never to require RTTI in throw_exception, ...
>
> The new throw_exception was not supposed to impose any new
> requirements and it certainly was not supposed to break code that
> worked before. (It almost succeeded at that.)
>
>> and Emil didn't know that, so he violated your original intent
>> unwittingly.  What about the "weight" of the header and its
>> dependencies?  Your usual stance is to avoid such things.
>
> Well, one upside is that exceptions thrown by boost::throw_exception
> now can be used with boost::exception_ptr. This makes exception_ptr
> more useful and requires zero effort from library authors who already
> throw all their exceptions via boost::throw_exception.

I understand the benefits. You've completely avoided my question ;-)

What about the "weight" of the header?  Did imposing it on clients of
boost::throw_exception concern you at all?  If you went through some
cost/benefit analysis (even in your own mind) I'd like to hear about it.

> The alternative way to provide such functionality would've been
> through a separate throw replacement, part of Boost.Exception. This
> would indeed have had zero impact on the rest of Boost, both in the
> negative and the positive sense. (That is, it would have required
> every library author willing to support exception_ptr to switch from
> boost::throw_exception to the new function.)

Yes, I understand that too.

> It was impossible to predict in advance whether going with option A
> would be worth the trouble. The only way to find out was to try.

Surely there must be another way to find out if library authors would
react badly to a dependency on Boost.Exception.  In fact, it might well
have been possible to sell everyone on the idea before the fact, but it
will be a lot harder to get Robert to accept it now.

> I think that (for such a major change) the transition went fairly
> smoothly. We still have the option to revert throw_exception if the
> "broad discussion" that should have happened then but is happening now
> reaches this conclusion.

I'm not sure it's the right conclusion to reach, but I do want to
discuss it.

> Either way, we'll still be ahead of where we were, both because we now
> have BOOST_NO_RTTI and some awareness of its significance, and because
> the new throw_exception caught a few bugs.

The impression I get is that for you, those benefits outweigh the costs
by such a wide margin that the costs aren't even worth mentioning.  Is
that right?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com