[boost] [exception][policy] (was: Should we provide hot fixes?)

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-27 14:13:15

on Wed Aug 27 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> David Abrahams wrote:
>> on Tue Aug 26 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>
>> If you know of cases where people broke backward compatibility in ways
>> that were irresponsible, it would be good to hear about those.  And it
>> wouldn't hurt for Boost to have a guidelines page on how to manage
>> interface evolution.  I might just write one.
>
> I'm referring specificly to the episode regarding boost exception
> where by the purpose of boost::throw exception was changed
> from a limited, lightweight piece of code crafted to address the
> simple problem that some compilers don't implement "throw"
> to a heavy weight (includes a bunch of new headers) module
> whose purpose is totally inpenetrable and adds RTTI requirement
> to any library which used boost::throw exception.  

This does look like a problem to me.

Hmm, I can't find any discussion on the list in which Peter Dimov, who
was the author of throw_exception, participated.  Did Emil get Peter's
approval for this change?

http://www.boost.org/doc/libs/1_36_0/libs/utility/throw_exception.html
still seems to imply that the implementation is as lightweight as ever,
and nowhere does it state that there are any constraints on the type of
the exception being thrown, although as Emil points out in
http://article.gmane.org/gmane.comp.lib.boost.devel/177620 they were
always there (discoverable by #defining BOOST_NO_EXCEPTIONS).

> The most gauling was that when i pointed this out, no one seemed to
> see this as a problem.  

Maybe the right people weren't reading your post.

> In fact, there was no acknowedgement that this was even an error. and
> no promise to fix it. I got the feeling that the author thought this
> to be perfectly legitimate given the new superior features (which are
> required by current users) and that I should plan for future episodes
> of this nature.

Well, I really hope I'm missing something, but from the evidence I see
before me, this was at least not handled well.  We have a Boost-wide
convention that libraries wanting to report errors on compilers with no
exceptions support use boost::throw_exception.  The change of
boost::throw_exception essentially made a Boost-wide policy decision
that such libraries, when they *do* throw, will integrate the
Boost.Exception machinery.  That shouldn't have happened without a
broader discussion.  

It's also a bit strange because it seems to me that the libraries that
want to be able to work with exceptions off are somehow less likely to
be interested in the functionality of Boost.Exception than the others,
and many of the other libraries still contain raw "throw" clauses.

> Which is what I've done by removing dependence on
> boost/throw_exception.hpp so its now and in the future a non-problem
> for me.  I have done something similar at least one time in the past.

I'd like to know more.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com