On Thu, Dec 15, 2016 at 11:26 AM, Robert Ramey
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.
These are false claims -- the change you're talking about went through the review process and it was immediately reflected in the documentation of boost::throw_exception, even though it didn't break existing code. There was no "coupling" to other libraries but to a single header with zero dependencies, which is now included in the boost::throw_exception submodule. Specifically, if you want to use boost::throw_exception, the Boost Exception submodule is NOT necessary.
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.
I agree 200% with your concern about coupling, so let's discuss that, rather than throwing around unsubstantiated claims. Any additions to boost::throw_exception should be self-contained. Even basic Boost components like function or shared_ptr should be off limits. The boost::exception type (which, again, does not depend on anything, boost/exception/exception.hpp does not include any headers) currently holds an int and a char const * for BOOST_THROW_EXCEPTION to store __LINE__ and __FILE__. The cost of adding the ability of boost::exception to carry a stack trace would be one more pointer (note: for this purpose it's possible to use Boost Exception's ability to transport arbitrary data in any exception, but that would make boost::throw_exception dependent on Boost Exception, which I've worked very hard to avoid so far.) That pointer can remain unused if the user chooses to turn off the automatic capture of the stack trace. Emil