Boost logo

Boost :

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

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