Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-15 15:21:18

On Thu, Dec 15, 2016 at 11:26 AM, Robert Ramey <ramey_at_[hidden]> wrote:

> 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.
>

These are false claims -- the change you're talking about went through the
review process and it was immediately reflected in the documentation of
boost::throw_exception, even though it didn't break existing code.

There was no "coupling" to other libraries but to a single header with zero
dependencies, which is now included in the boost::throw_exception
submodule. Specifically, if you want to use boost::throw_exception, the
Boost Exception submodule is NOT necessary.

> 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.

I agree 200% with your concern about coupling, so let's discuss that,
rather than throwing around unsubstantiated claims.

Any additions to boost::throw_exception should be self-contained. Even
basic Boost components like function or shared_ptr should be off limits.

The boost::exception type (which, again, does not depend on anything,
boost/exception/exception.hpp does not include any headers) currently holds
an int and a char const * for BOOST_THROW_EXCEPTION to store __LINE__ and
__FILE__. The cost of adding the ability of boost::exception to carry a
stack trace would be one more pointer (note: for this purpose it's possible
to use Boost Exception's ability to transport arbitrary data in any
exception, but that would make boost::throw_exception dependent on Boost
Exception, which I've worked very hard to avoid so far.) That pointer can
remain unused if the user chooses to turn off the automatic capture of the
stack trace.

Emil