Boost logo

Boost :

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-07-09 15:25:41


> Absolutely not. In what sense is the program more
> exception-safe with the
> exception-specification than without it?
>
> You might convincingly argue that the program is more safe against
> programmer mistakes (like violating a contract which says
> you're not allowed
> to throw), but only if you consider termination to be an appropriate
> response to such a mistake.

I had in mind cases where the programmer simply doesn't know what code his
code calls might throw. This is a very real problem in large production
codebases, which tend to get inherited by the new guy because the people who
wrote them can't stand the sight of them anymore and want to move on to
something else. I'm stuck in exactly that position right now, twice
removed, because the people who wrote the original version are long since
gone, and the people who kludged the last version didn't understand it well
enough to use it the way it was intended, and so now I have to work with a
code base that *no one* understands, save for the small piece of it he
wrote, and no one has time to explain even those small pieces to me, let
alone give an overview. So I would argue that yes, it's exception-safety
against programmer mistakes, but not the current programmer's mistakes.

> I know the Sun compiler does it. I don't know of any others.
> In particular, I know Metrowerks doesn't do it, though their EH
> implementation is excellent in many respects.
> FWIW, VC++6 has a much less-efficient implementation of EH,
> contains serious
> bugs that can result in double-destruction of thrown
> exceptions, and has
> some bad interactions between catch(...) and post-mortem debugging.
> Metrowerks suffers none of these problems.

Good info. Thanks.

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

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