Re: [boost] [exception] library update

Subject: Re: [boost] [exception] library update
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-09-10 01:05:11

----- Original Message ----- 
From: "Emil Dotchevski" <emil_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 09, 2008 8:46 AM
Subject: Re: [boost] [exception] library update

>
> 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.)

The previous documented semantics do not requires that the exception 
parameter should be derived from std::exception

"When BOOST_NO_EXCEPTIONS is not defined, boost::throw_exception(e) is 
equivalent to throw e. Otherwise, the function is left undefined, and the 
user is expected to supply an appropriate definition. Callers of 
throw_exception are allowed to assume that the function never returns; 
therefore, if the user-defined throw_exception returns, the behavior is 
undefined."

>> 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. :)

If users care about the benefits of the "old" boost::throw_exception 
behavior they will complain and finish to use the 
boost::serialization::throw_exception.

>> 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?

I have any, but unser a specific name e.g. 
boost::exception::throw_exception.

What reasons do you had for avoiding the old 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.

boost::exception::throw_exception would offer the same.

> 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%.

Why to pay for +1% when I don't need if I can pay 0%?

> 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.

BTW, are we testing on a compiler without exception support and 
BOOST_NO_EXCEPTION defined? Do we have some tests on these configuration?

> So what's the upside?
>
> - The ability to transport Boost exceptions between threads.

The ability to transport every exceptions, and not only Boost exceptions, 
must be on the current_exception function, not on the throw_exception 
function. There is no throw_exception onthe proposed standard!
If I need to use throw_exception to ensure this, I need to add a try-catch 
which is much more expensive than storing thre pointers, and this must be 
done independently if a exception is thrown.

> - 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.

I agree with you that boost::exception give these abilities, and I really 
think that this class is a very interesting. When a user want to use these 
abilities what he needs is just to use it  directly. That's all!

I really think that boost::throw_exception should preserv its old behavior 
(semantics), and the current_exception should be able to return an 
exception_ptr to the current exception for any exception. I have proposed a 
way to achieve this, but you have not made any comment on this.

Vicenet