Re: [boost] [Boost] [Stacktrace] review

On 12/15/16 12:21 PM, Emil Dotchevski wrote:

On Thu, Dec 15, 2016 at 11:26 AM, Robert Ramey wrote:

...

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,

Hmmm - When this occurred I wondered how such a thing could get through the review process as I was totally surprised by it. My recollection was that when I looked back at the mailing list, it only received a very small number of reviews - like 2 or 3/. Unfortunately, the announcement of acceptance didn't include a summary of how many reviews were received and I can't find the mailing list entries to verify this. even though it didn't break existing code. It added a ton of included code to all my header files. I think the number was 5000 lines. I'm sure it did something - otherwise I wouldn't have noticed it.

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.

that's what coupling is. Specifically, if you want to use boost::throw_exception, the

Boost Exception submodule is NOT necessary.

well, I was using boost::throw_exception and I was got a whole bunch of new stuff I didn't ask for. It seems that it's in there to support other users who do use boost exception. Which raises the question of why that is my problem. After not getting any traction I did post a patch which would permit support boost exception without having to make any changes in boost::throw_exception. It turned out I had accidentally "re-invented" nested exceptions which were in the standard library. This would have been a good solution but it was never incorporated.

...

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.

OK - I looked at boost/exception/exception.hpp and it only adds 500 lines of header code to every file which invokes boost::throw_exception. A big improvement over the original. But my point is really that adding something like this in jamming into my library makes me responsible for something that I have to invest significant time to understand. It increases the scope of my task and provides me with no benefit. I don't think you have the right to make a decision to do this - especially without previous discussion. We went through this the last time though. As a practical matter, it's not really an issue any more. Robert Ramey