Boost logo

Boost :

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at