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

Subject: Re: [Boost-users] exception, filesystem, system_error and consistency
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-06-12 03:16:14

Emil Dotchevski wrote:
> On Sat, Jun 11, 2011 at 4:00 PM, Robert Ramey <ramey_at_[hidden]> 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