Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-12-15 16:24:13

On 12/15/16 12:21 PM, Emil Dotchevski wrote:
> 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,

Hmmm - When this occurred I wondered how such a thing could get through 
the review process as I was totally surprised by it.  My recollection 
was that when I looked back at the mailing list, it only received a very 
small number of reviews - like 2 or 3/.  Unfortunately, the announcement 
of acceptance didn't include a summary of how many reviews were received 
and I can't find the mailing list entries to verify this.

even though it didn't break existing code.

It added a ton of included code to all my header files.  I think the 
number was 5000 lines.  I'm sure it did something - otherwise I wouldn't 
have noticed it.

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

that's what coupling is.

Specifically, if you want to use boost::throw_exception, the
> Boost Exception submodule is NOT necessary.

well, I was using boost::throw_exception and I was got a whole bunch of 
new stuff I didn't ask for.  It seems that it's in there to support 
other users who do use boost exception.  Which raises the question of 
why that is my problem.  After not getting any traction I did post a 
patch which would permit support boost exception without having to make 
any changes in boost::throw_exception.  It turned out I had accidentally 
"re-invented" nested exceptions which were in the standard library. 
This would have been a good solution but it was never incorporated.

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

OK - I looked at boost/exception/exception.hpp and it only adds 500 
lines of header code to every file which invokes boost::throw_exception. 
  A big improvement over the original.

But my point is really that adding something like this in jamming into 
my library makes me responsible for something that I have to invest 
significant time to understand.  It increases the scope of my task and 
provides me with no benefit.  I don't think you have the right to make 
a decision to do this - especially without previous discussion.  We went 
through this the last time though.  As a practical matter, it's not 
really an issue any more.

Robert Ramey