<snip>
So now you're bringing up a different use case.
... I'm bringing up the different use case because -- at least in my experience -- it is very common when using boost::exception; I'm trying to convince the audience that the effort to bundle multiple pieces of data together perhaps isn't as beneficial as one hopes, because a lot of times all you have is a single piece of data that is relevant to a failure.
I agree. But that use case will become even nicer if you don't have to throw the boost::exceptionS yourself as it's done by the components you use, won't it?
Can you please clarify what do you mean? I do not understand the above paragraph at all...
As you expressed you'd like boost::exception to become THE exception class, I think you should make it as flexible and inviting to use as possible: There is a whole bunch of existing (and stable) code that uses traditional exception classes. Providing means for a smooth transition will probably increase your library's acceptance.
I don't want to get in an argument with my review manager :) but I don't think I've said that I want boost::exception to become THE exception class; it's designed to act as a base class for user-defined exception types much like std::exception is used today. As for integration with existing exception classes, Boost Exception provides a special function called enable_error_info which makes integrating it into existing code base safe and easy: http://www.revergestudios.com/boost-exception/boost-exception.htm#enable_err... Integration in Boost is even easier, as it can be done in a single place, in the boost::throw_exception function.
Same goes for avoiding boilerplate code and overhead compared to the traditional approach.
Could you please explain? How does using Boost Exception require more boilerplate code than the traditional approach? Emil Dotchevski