Re: [boost] Boost and exceptions

22 Jun 2012

      John Maddock wrote:
...
...
...
I just don't want to see a new throw_exception()
variant if there isn't a compelling reason, and I don't consider
your fragility argument compelling in this case.)
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.
...
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.
...
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.
...
3) Boost.Exception provides additional information about from where
the exception was thrown (file and line number etc), this can be
extremely    useful in diagnostic situations when an exception was 
"unexpected". See
http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/tutorial_diagnostic_....
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.

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

Robert Ramey