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_transportin.... 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.... 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. HTH, John.