Re: [boost] [Stacktrace] review

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
> of BOOST_THROW_EXCEPTION. Hello Java.

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

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