Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-22 16:17:36

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_transporting_data.html.

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_ptr.html.

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_information.html.
>
> 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