You've looked into this - did you see any "compelling reason" to inject this code into the serialization or any other library?
Let's try and give some examples:
I really didn't want to get is these specifics. But you've sucked me in.
Huh? I thought that's what you were asking for when you asked for "compelling reasons".
1) Unlike "regular" exception objects, objects which derive from boost::exception can have additional information added to them either at the call site, or later in the call stack. Consider this case: user opens a std::fstream and passes the object to a serialization method which then throws. Currently you may get some information about the failure, but not the file name because serialization doesn't know what that is (as far as I know). However, with Boost.Exception support, the calling code can annotate the already thrown exception, retaining all the information it contains, but adding whatever extra information (file name for example) is available. See http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/tutorial_transportin....
Why does the serialization library have to include code from boost exception in order to do this?
You can use boost exception at the same place, catch the standard exception that the serialization throws, construct you're own boost exception and continue on.
No!!!! Misses the whole point - Boost.Exception allow you to annotate an existing exception without loosing the original information - and that includes the *type* of the original exception.
2) As others have already mentioned, Boost.Exception allows arbitrary exception objects to be cloned, amongst other things, this allows exceptions to propagate across threads. For example if a serialization routine is run as a future (quite a reasonable goal), then it would allow exceptions thrown during serialization in the worker thread, to be re-thrown in the calling thread when the result of the future is acquired. See http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/tutorial_exception_p....
again the same question.
Consider writing a future - in order to preserve all the exception information, you would have to be able to catch, clone, and then rethrow *every possible exception type* that may be thrown by the code that the future calls. It is quite simply impossible. However, if all thrown exceptions inherit from boost::exception, then you simply catch that exception type, ask it to clone itself, and rethrow in a different thread. You preserve all the original error information, and crucially, all the original type information, even though the future doesn't itself know what the actual dynamic type of the caught and rethrown exception is. This actually looks compelling enough to me, that we should probably mandate use of BOOST_THROW_EXCEPTION.
For me, I've only used (3), but when you need it it's very useful. Both (1) and (2) look like killer use cases to me - not for you - for your users.
Let me be clear. I don't have any complaint about boost exception per se.
My complaint is the process by which it was inject.
Fair enough, but you're still 4 years too late on that one. I repeat an earlier question - if Boost.Exception were refactored to put the "core" exception throwing code either into boost/detail/ or indeed directly into boost/exception.hpp given that there's not much of it, would that address at least some of your concerns?
BUT - now you've sucked me into looking at the merits of including it, I don't see that it would be of any use. here's typical serialization code:
#include <boost/archiive/binary_iarchive.hpp> #include <ifstream> ... f(...){ ifsteam is("my file") binary_iarchive ia(is); try { my_data d; ia >> d; } catch(boost::archive::exception ae){ std::cout << ae.what(); throw(ae) ; // or throw something else } return; }
So if I want to use boost exception I would just write
#include <boost/archiive/binary_iarchive.hpp> #include <ifstream> #include <boost/exception/???.hpp> ...
f(...){ ifsteam is("my file") binary_iarchive ia(is); try { my_data d; ia >> d; } catch(boost::archive::exception ae){ std::cout << ae.what(); // I don't know how to use boost::exception insert your own code here boost::exception::throw(?) } return; }
I don't see injecting boost::exception into the serialization code changes this in any way
Please see my answers above. Now consider that the serialization code includes some use of Boost.Filesystem, Boost.Regex (filename parsing) and heaven known whatever other dependencies the object being [de]serialized depends on (presumably an object being deserialised could throw any exception Boost is capable of). If all those exception objects uniformly derive from boost::exception somewhere in their object hierarchy, then you catch *one* exception type, annotate it, and rethrow. All the original type information is retained, clients can catch the boost::exception and enumerate all the information it holds, or they can catch something more specific like boost::archive::exception and work from there. I admit to being new to what boost::exception has to offer, but that looks pretty compelling to me, Cheers, John.