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-11 19:00:17

Michael Schuerig wrote:
> On Saturday 11 June 2011, Emil Dotchevski wrote:
>> On Fri, Jun 10, 2011 at 1:09 PM, Michael Schuerig

>> With the introduction of Boost Exception, we now have a single base
>> exception type for Boost libraries to use, but rather than modifying
>> all existing Boost libraries, the boost::throw_exception function
>> (which most Boost libraries have always been calling to throw
>> exceptions) was modified so that the object it throws is guaranteed
>> to derive from boost::exception. This is done at the point the
>> throw_exception template is instantiated: if you pass it an object of
>> type T which doesn't derive from boost::exception, it is wrapped in a
>> type that derives both from T and from boost::exception (this
>> mechanism is formally documented here:
>> http://www.boost.org/doc/libs/release/libs/exception/doc/throw_except
>> ion.html)
>
> Yes, I had seen that in the docs, but there's also this bit in
> filesystem/v3/config.hpp:
>
>  //  Exceptions were originally thrown via boost::throw_exception().
>  //  As throw_exception() became more complex, it caused user error
> reporting
>  //  to be harder to interpret, since the exception reported became
> much more complex.
>  //  The immediate fix was to throw directly, wrapped in a macro to
> make any later change
>  //  easier.
>
>  #define BOOST_FILESYSTEM_THROW(EX) throw EX
>
> What am I supposed to make of this? The wording of the comment
> suggests that the implementers of boost::filesystem have tried to use
> boost::exception, but as it has proved unwieldy, they are not using it
> anymore.
>
> Now, for me, still being new to boost, that sounds like a strong
> advice to "do as we do". I don't understand all the subtle issues
> involved, so I may better keep away from boost::exception, too. I
> certainly won't just redefine BOOST_FILESYSTEM_THROW to
> BOOST_THROW_EXCEPTION.
>
> I may be overdramatising just a tiny bit, but the issue stands that
> these real or perceived inconsistencies have a strong impact on my
> impression of boost. I was approaching boost with the expectation of a
> set of well-coordinated libraries, coming with the recommendation "if
> you do it at all, do it like this". For me, this picture has got
> cracks.

You're not overdramatizing at all.  In fact, it's just the opposite - you're
UNDERdramatizing.  The serialization library used the original boost
exception functionality.  This original functionality was such that
it handled the case where the compiler didn't support (or the environment
didn't want to support) normal C++ exceptions.  This is common
in things like embedded systems.  All of a sudden, the symantics of
the boost excpetion changed.  This made available new functionality
which no current libraries used and added many lines of header source
to every module which used it.  It also broke any libraries built without
RTTI - another valid case.  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.  Changing
the functionality of an existing function is a bad idea.  I just can't 
understand
why not everyone can see that.

Robert Ramey