Re: [Boost-users] exception, filesystem, system_error and consistency

Emil Dotchevski wrote:

On Sat, Jun 11, 2011 at 4:00 PM, Robert Ramey wrote:

The change doesn't break anything that wasn't already broken under the old semantics.

Hmmm - I remember it breaking serialization which as far as I know wasn't broken at the time.

...

This made available new functionality which no current libraries used

You're missing the point. Even if a Boost library, say Serialization, doesn't use the functionality of Boost Exception, the users of Boost Serialization could still use it.

Ahhh so now every library has to include something it doesn't use just because some other library might use it? So an application which wants to use it's own exception handling setup can't use any boost library?

Your argument boils down to "I don't care if anyone needs to transport Serialization exceptions to another thread. Tough!"

When writes a multithreaded ap, there is no expectation that exceptions will be passed from one thread to another without some sort of special treatment. This is doable in an obvious way. I can see how some sort of library might be helpful here. BUT there's no excuse for changing the behavior of a default exception mechanism to handle this case. It creates unnecessary "hidden" coupling. I'm guessing this is why a number of libraries have been changed not to include this.

...

and added many lines of header source to every module which used it.

About 400 lines. That code enables (does not implement) the functionality of Boost Exception. There is no way for anyone to make use of Boost Exception without that code.

not everyone (anyone?) makes use of Boost.Exception. But we all have to include another library with unexpected/unanticipated behavior

...

It also broke any libraries built without RTTI - another valid case.

That was fixed long ago.

Good to know.

...

I complained about this at the time but I couldn't get any traction. I would have had no objection if the new exception had been an option - but it's invaded everything - I just used the thread library, and had a problem because of it.

Please do report problems you have.

lol - I did this when it broke my debugging setup. The response I got seemed to suggest I was doing something I shouldn't be doing -- even though trapping when exceptions are thrown is perfectly legitimate. The idea that one is going to significantly change the functionality of a particular component already in use by a number of other libraries is really a bad idea and creates all sorts of uncertainty and surprises. Developers shouldn't have new behavior inserted into their code unless the specifically want to include it. I'm still at a loss to understand how this got through the review process. I admit I can't follow every review with an eye to possibility that just being included in boost is going to break my code or change it in a subtle and surprising way. But I shouldn't have to do this. Robert Ramey

Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode