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.
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.
Again - a matter of opinion. A typical program these days will use libraries from several sources as well as internal code. It's going to be difficult to make an exception design/policy for one's application when it is set from within the library to a module whose semantics can and have changed without notice.
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.
LOL - well, I'm just illustrating your point here. 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. It engenders all the disputes like we constantly have about testing, deployment, documentation, build systems etc. This is one thing that the standard C++ library does better. There is less coupling between individual components. (Of course the standard library has it's own issues but we're not touching on them here.) Getting back to the main point, the boost policy for exception handling has been short sighted and the manner that it was imposed - by code ambush - not appreciated by some of us. I don't want to dwell on it since I lost that war a long time ago and I've tried to moved on. Robert Ramey