Emil Dotchevski wrote:
<snip> 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...
I mean that Exception becomes more useful the more other libraries use it.
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.
OK, then I probably misinterpreted this one: <cite> In my ideal world, the functionality of boost::exception would be implemented directly by std::exception ;) </cite>
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...
Oh my, I missed it. I should've read this part of the reference docs inspecting the library as that multiple inheritance approach seems highly questionable to me for the following reasons: 1. We can't access the data in the "traditional exception" the Boost.Exception way (it's not tagged), and 2. calling 'what' is probably ambiguous and it seems generally awkward to deal with that exception where (finally) caught. One could argue there is no integration at all as its basically just two independent classes lumped together.
Integration in Boost is even easier, as it can be done in a single place, in the boost::throw_exception function.
While technically possible, this measure requires the authors of throwing libraries to reach consensus that it should happen - and a single developer with objections might blow that plan.
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?
I mean the throw site: throw an_error(a,b,c) vs. throw an_error() << boost::error_info<a_tag>(a) << boost::error_info<b_tag>(b) << boost::error_info<c_tag>(c) Currently it adds both boilerplate code and overhead when porting existing code (in a way so that it throws first-class Boost.Exceptions, that is). Regards, Tobias Schwinger - Review Manager -