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