Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-07-13 08:01:43


> That's a key question, which I am not yet ready to answer. It would
> seem that the answer to that question is the same as the answer to
> "Why are exception specifications in C++ in the first place?"

I recently asked Bjarne this, and the only answer I could get was something
like this (I'm paraphrasing of course): "If an unexpected exception is being
thrown there is something seriously wrong with the program, so you terminate
rather than continuing."

> My best answer is that they allow the programmer to use the class
> knowing he must only code to handle certain exceptions.

See above. I don't think the motivation was anything like that. Remember,
the contract is enforced with termination semantics. Also, exceptions
usually only have to be handled "by type" for error-reporting purposes. That
can happen in one place in a program.

> Another plus, as has already been brought up in this thread regards
> debugging. You can put an assert(false) in unexpected and trap
> unexpected exceptions closer to the source.
>
> Are these benefits (and other's I can't think of) worth the cost
> of the implicit try block today. I would guess not, but in the
> future if try blocks become free (I would appreciate more details
> on that subject), then we can freely reap the benefits.

Whether being forced to terminate or translate the exception should be
considered a benefit or not is still definitely up for debate. In my
opinion, even aside from efficiency issues, there are still way too many
problems inherent in code using exception-specifications to make them worth
the trouble. As a matter of fact, aside from the use as an assertion I see
no benefits at all.

-Dave

P.S. I don't really want to continue this discussion here, since it's pretty
much all a rehash of stuff that's been said before. If you search dejanews
for my postings on exception-specifications, you'll find all the arguments
spelled out in exquisite detail.

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk