On Mon, Jun 25, 2012 at 11:50 AM, Robert Ramey <ramey@rrsd.com> wrote:
permit catch X rather than catch boost::exception which syntatically looks clean.
This is not syntactic sugar. I am surprised that I have to defend the position that if a library's documentation says "the library throws X" then the application can catch(X &).
But now you've got an interface - catch X which actually is an X++. To me this is very bad practice. It hides too much. It's not at all obvious whether or not one can extract extra data from this - it depends on how the exception is thrown.
Look at the postcondition of op<< ( http://www.boost.org/doc/libs/release/libs/exception/doc/exception_operator_...). As a matter of fact, users can rely on library exceptions to always arrive with various application-specific data at the catch site. I would like to know that if I catch a "my_exception" that's what
I'm getting no more no less. My interface makes this much clearer.
Like Peter said, others have argued your position in the past and the result is that C++ has exception specifications. I'm warning you, there are dragons down that route, you don't want to go there.
That is, I think
catch Z // this had to change is much better than catch X // where X is really an X + some other data
One more thing to argue about.
Looking at my make_exception_wrapper, it might be possible to use the boost exception technique so on could replicate the catch X behavior if he wanted to.
How?
Really, it's just not practical that for a library to be useful one has to require all the users to change their exception throwing code. How does boost exception deal with third party libraries for which we don't even have the source code?
There are limits to what can be done. Can Boost Serialization serialize any object from a third party library for which we don't even have the source code -- or even if we have it?
FWIW - The assertion was that it was not possible to implement functionality of boost exception without wrapping exceptions at the throw site. I believe I have shown a counter example to this assertion.
You've shown that something different from what Boost Exception can be implemented with std::exception_ptr, which very few compilers support anyway. OTOH, you could use boost::exception_ptr to implement your wrapping code on pretty much any compiler, though -- bummer -- that won't work for exceptions emitted by Boost Serialization. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode