Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-22 14:11:14

>> 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:

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

HTH, John.