From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-10-02 20:02:14
Emil Dotchevski wrote:
>> 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:
In my ideal world, the functionality of boost::exception would be
implemented directly by std::exception ;)
> 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:
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() << 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,
- Review Manager -
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk