RE: [boost] Exception usage (was: Threads by Jeremy and Monitors in one?)

From: Reid Sweatman (borderland_at_[hidden])
Date: 2000-08-14 04:14:13

> -----Original Message-----
> From: David Abrahams [mailto:abrahams_at_[hidden]]
> Sent: Sunday, August 13, 2000 9:48 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Exception usage (was: Threads by Jeremy and
> Monitors in one?)
>
>
>
> ----- 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?)

Somehow I knew that one was going to draw a reply <g>.  But you'll notice
that I *did* hedge my original claim with "It would depend on whether or not
the information necessary to do the repair is available locally."  In every
other instance (most of them, probably, as you say) you couldn't do it.  I
wasn't trying to make much of a case, just maintaining that there *are*
instances, albeit rare, where you can recover from a broken invariant.
Again, as you say, it also depends on the amount of code affected by the
invariant, and timing.  I wouldn't try to repair a broken invariant other
than very locally (say within a class with no affected dependencies where I
had a reasonable fix for the break).  In case this doesn't make it clear,
let me say that while I *do* include invariant testing in non-trivial code,
I've never tried to do the kind of fix I mentioned, nor shall I in the
future.  (I suspect there are still a couple of bombs in this paragraph
that'll provoke a response <g>).

Reid Sweatman
Software Provocateur