----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> 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@wanadoo.fr> 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