Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-12-14 19:53:27

On 12/14/16 3:27 PM, Peter Dimov wrote:

> 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

I think that there has been a lot of confusion about what
BOOST_THROW_EXCEPTION is suppose to do.

My understanding was that it was a macro intended to support the writing
of portable code that could run on platforms which didn't support
exceptions or where the user / author didn't want to use the exception
mechanism so he could redefine the macro. Lot's of libraries used this
idiom to decouple their libraries from the the selection of exception

With the acceptance of Boost.Exception, this BOOST_THROW_EXCEPTION was
repurposed to call boost.exception. Obviously not what previous users
of BOOST_THROW_EXCEPTION intended or expected. This made many libraries
dependent on the new library boost.exception which had multiple
repercussions - one of which is that boost.exception has now become a
"core library" - not sure what that is supposed to mean.

Now it's being suggested that BOOST_THROW_EXCEPTION be
repurposed/enhanced yet again? Is this really a great idea? Wouldn't
it better just to encourage authors of library authors to use their own
code to throw exceptions and implement this code in the way most
suitable for their own libraries? Of course the stack trace library
might want to address this subject in the documentation and perhaps
provide it's own macros or wrappers to facilitate the usage of this
facility in other library code but the responsibility for a library
implementation would still remain with the library author/maintainer.

Robert Ramey

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