Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-13 10:48:29


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

> > > Yes, a broken precondition
> > > should be fatal, whereas a class-invariant problem may not be.
> >
> > Er, how so? If a class invariant is broken, the precondition to any of
its
> > member functions is broken, too.
>
> Depending on just what the broken invariant is, it may be possible to fix
it
> before it matters, probably by letting the invariant test try to patch it
> up. It would depend on whether or not the information necessary to do the
> repair is available locally.

I think you will find that this just adds useless complexity to your code.
If you discover a supposed invariant is broken, who knows how many other
things are are also out-of-whack? Is your "patch-up" designed to restore the
program state to its full correct condition, or just do something plausible
locally? If the latter, what faith do you have that you've done the right
thing? It's hard enough to write and test error-recovery code for
predictable conditions, like running out of memory, without trying to deal
with the unpredictable (A and B are supposed to agree, but somehow they
don't - who knows why?)

-Dave


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