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