Re: Exception specifications in smart_ptr.hpp

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-07-16 15:59:59

--- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> From: Howard Hinnant <hinnant_at_t...>
> > David Abrahams wrote on 7/16/2000 11:29 AM
> > >I'm surprised to hear that they
> > >crept back in.
> > 
> > No I don't think they should be banned.  Though I will admit that 
I would 
> > vote against they're use in every project I'm currently familiar 
with.  
> > But I think they should be considered on a case by case basis, 
and not 
> > banned with a blanket statement.  They provide a runtime behavior 
that 
> > could be desirable in some circumstances.

To reiterate my position, I think we ought to ban them only _as a 
general rule_. I take this position in part because even seasoned 
programmers tend to misuse exception-specifications, misinterpreting 
them as a convenient way of specifying the exceptions a function may 
throw. If in specific cases the use of exception-specifications can 
be shown to be an advantage on a particular compiler, then by all 
means, we should allow them to be used. Regarding the runtime 
behavior, well, I'm sure most of you know how I feel about that:
in most cases something sufficiently similar and useful (and less 
deadly) can be achieved with try/catch blocks. If we really want 
exactly the behavior of an exception-specification, then by all means 
we should use an exception-specification! So, what I'm saying is that 
the use of exception-specifications should be strongly discouraged, 
which is what I thought we had decided all along.

> Given the state of current compilers exception specifications
> usually do more harm than good on inline functions.  It's
> unforunate that this is true, because the "throws nothing"
> specifications in shared_ptr aren't there for runtime behavior,
> they are there as *specifications* that certain operations will
> not throw, by design.  If we are forced by low compiler quality
> to remove the specs we should add comments and documentation so
> that users can count on this design.

That is arguably a better approach anyway. I could have _sworn_ 
that's what we decided to do.

> For non-inline functions "throws nothing" specs may allow
> optimizations that help more than their overhead hurts.

Maybe. That might even be true for inline functions; it really 
depends on the compiler. In my experience the negative effects on a 
compiler which can't use the optimization are much greater than the 
positive effects on a compiler which can. That's why I'd like to have 
a general guideline which is violated only with suitable 
justification, rather than having to prove this point to each new 
library author.

-Dave