Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-11 21:07:27


----- Original Message -----
From: "Reid Sweatman" <borderland_at_[hidden]>

> I think you just put me closer to understanding the problem. As I had
> understood it, exceptions were used in cases where the class contract was
> violated. However, preconditions are part of the contract, and, as you
say,
> assertions are the way to go there. But then, that raises the whole issue
> of whether the class contract as a whole should be enforced by invariant
> testing; maybe only throw if the invariant test fails. Seems to me that
> what has happened in the spec is that several differing mechanisms have
been
> created to handle problem domains that have a lot of spill-over, making it
> unclear which to use for any given purpose. If that's actually the case,
> then any attempt to sort out exactly what you can legitimately use an
> exception for is doomed from the get-go. Still you need some kind of
> convention, or you're certainly going to get errors in exception usage
based
> on different perceptions of their purpose, especially on large projects.

I don't think so. Just consider the behavior you want, and all will be well.
When I programmatically detect a bug in my code, a.k.a violation of
precondition, I want the program to stop at the point of detection, and give
me an opportunity to inspect the exact program state. Once a precondition is
violated, I have little faith in any error-recovery efforts that might be
achieved through stack-unwinding: as far as I'm concerned, the program state
is corrupted, and some whole-program invariant has been violated.

> I'm beginning to understand why some people here aren't too gung ho on
> exceptions to begin with.

I don't understand that last bit.

-Dave


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