Re: [boost] [exception] library update

Subject: Re: [boost] [exception] library update
From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-09-09 02:46:38

On Mon, Sep 8, 2008 at 10:31 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:

> I don't know if this will be enough. For me the semantics has ben changed

Could you please elaborate on this? (Hint: one possible definition of
changed semantics is that the current behavior of
boost::throw_exception is incompatible with the the previously
documented behavior.)

> Robert has already created its own serialization::throw_ewception which is a
> copy of the old boost::throw_exception, who will be the next?

There are also Boost libraries that use throw directly, without
calling any function. If there is a requirement for all Boost
libraries to throw using boost::throw_exception, I'm certainly not
aware of it.

If users care about the benefits of the "new" boost::throw_exception
behavior (if it stays, which is obviously subject to discussion), they
will complain that the Serialization or some other library doesn't
call it. If not, all is good. :)

> IMO, we need to provide the old boost::throw_exception publically on boost,
> even if we change its name,  before each library developer and user define
> its own throw_ewception.

What reasons do you have for avoiding the current throw_exception behavior?

> Can you provide some performance results comparing the old and the new
> implementations?

1) The performance cost of the current boost::throw_exception compared
to the previous boost::throw_exception is the added zeroing of 3
pointers and an int.

2) Even if there was a measurable degradation in performance, it only
occurs if an exception is being thrown. Therefore, it has to be
compared to the overall speed of propagating an exception up the call
stack (hint: often, this is a rather slow process.)

There are two valid concerns with the "new" boost::throw_exception:

A) Source code bloat: throw_exception.hpp is a major coupling point in
Boost and as such, anything included by it has the potential of being
included by many libraries, and, due to the mostly header-only nature
of Boost, by the end user.

Here is some cold data: on my system, preprocessing
throw_exception.hpp results in ~30,000 lines of code, of which the
added weight of boost/exception/exception.hpp is ~400 lines. Of
course, throw_exception.hpp itself doesn't do anything. Including
something that's actually useful yet minimal -- for example
intrusive_ptr.hpp -- equals ~40,000 lines of code; shared_ptr.hpp:
~55,000 lines. In this case, the overhead is < 1%.

B) Maintenance problems: we've already seen one bug in
throw_exception.hpp escape undetected by our testing process, until it
was reported by the end users. Clearly, any change in
boost/exception/exception.hpp has the potential of breaking many
libraries which -- I know -- is a major headache.

So what's the upside?

- The ability to transport Boost exceptions between threads.

- The ability to catch any (well, most) Boost exceptions.

- The ability to augment active exception objects with important
information that is relevant to the failure but is not available at
the point of the throw.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode