Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-12-15 14:26:57

On 12/15/16 9:37 AM, Peter Dimov wrote:
> Robert Ramey wrote:
>> It wasn't BOOST_THROW_EXCEPTION. It was boost::throw_exception whose
>> semantics were changed in an unanticipated and surprising way. It
>> seems to me that it might be that this was being proposed again.
>> Maybe my concerns are overblown as those who got burned the first time
>> by this policy have already eliminated dependency on
>> boost::throw_exception.
> The whole point of using a central infrastructure for throwing
> exceptions (and asserts) is for us to be able to (carefully and after
> due deliberation, and in the interest of our users) apply changes to it
> which magically affect all Boost libraries without their maintainers
> having to do anything.

I understand the motivation for this. Still it's a very bad idea. It
changes the behavior of code in a silent, undocumented and sometimes
surprising way. It couples one library to another in a way which can
make the library inconvenient to use with other libraries.

> Last time the effect of the changes has been to make all Boost-emitted
> exceptions Boost.Exception enabled and, if the macro is used, to contain
> the file/line/function. This has a number of benefits and the downsides
> have been kept to a minimum.

Again - a matter of opinion. A typical program these days will use
libraries from several sources as well as internal code. It's going to
be difficult to make an exception design/policy for one's application
when it is set from within the library to a module whose semantics can
and have changed without notice.

> It's normal for changes to the default behavior of such a critical piece
> to be controversial and we won't make them without a consensus. Which is
> why I originally said
>> This sounds like a pretty good idea, although I'm not sure if we can
>> enable it by default as people have historically been very sensitive
>> to changes to BOOST_THROW_EXCEPTION. But an opt-in macro should be
>> fine and very useful as one would automatically get stack traces from
>> every use of BOOST_THROW_EXCEPTION.

LOL - well, I'm just illustrating your point here.

It's really a much deeper point here. What is a boost library? Is it
necessary part of something large - the "Boost Libraries" or does it
stand on it's own - the boost serialization library. The former view is
natural to developers who think in terms of "releasing" a humongous
product. Its natural to want to couple things like exception policy,
testing, build, etc. etc. as a more or less monolithic system. It
"seems" to make things easier. But it doesn't really - not in our
context. It engenders all the disputes like we constantly have about
testing, deployment, documentation, build systems etc. This is one
thing that the standard C++ library does better. There is less coupling
between individual components. (Of course the standard library has it's
own issues but we're not touching on them here.)

Getting back to the main point, the boost policy for exception handling
has been short sighted and the manner that it was imposed - by code
ambush - not appreciated by some of us. I don't want to dwell on it
since I lost that war a long time ago and I've tried to moved on.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at