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. Last time the effect of the changes has been to make all Boost-emitted exceptions Boost.Exception enabled and, if the macro is used, to contain the file/line/function. This has a number of benefits and the downsides have been kept to a minimum. It's normal for changes to the default behavior of such a critical piece to be controversial and we won't make them without a consensus. Which is why I originally said
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.