From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-10-02 14:20:17
> <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_error_info
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