Re: [boost] [Stacktrace] review

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