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

Subject: Re: [Boost-users] exception, filesystem, system_error and consistency
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-06-12 03:36:47

On Sun, Jun 12, 2011 at 12:16 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>> 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?

No, not some other library.

We're talking about a *user* of Boost Serialization wanting to
transport to another thread an exception Boost Serialization throws.
Or a *user* of Boost Serialization wanting to record their own
information in exceptions Boost Serialization throws.

>> 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.

To transport the exception, you need to copy it. In many cases or in
generic contexts, copying an (exception) object isn't possible,
nevermind obvious. Note that often multi-threaded systems execute
arbitrary or user-defined functions which may throw any exception.

>  I'm guessing this is why a number
> of libraries have been changed not to include this.

I am not concerned about libraries not using boost::throw_exception,
my only concern is that such a choice is made on behalf of users of
those libraries.

>>> 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

In your mind, how does Boost Exception interfere with the usual
semantics of exception handling?

>>> 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.

Even though it wasn't a bug, this problem was fixed.

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