On Saturday 11 June 2011, Emil Dotchevski wrote:
On Fri, Jun 10, 2011 at 1:09 PM, Michael Schuerig
wrote: Poring over docs and headers, I noticed that neither boost::system::system_error nor boost::filesystem::filesystem_error are derived from boost::exception. Instead they implement an independent exception hierarchy.
I found this disconcerting. For one thing, I have to catch and handle the respective exceptions separately. Far more importantly, though, I was expecting consistency among boost libraries and now see that this is not the case apparently.
The reason for this discrepancy is that Boost Exception was added later than boost::filesystem and boost::system.
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. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/