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