Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk