From: Alan Brain <aebrain@dynamite.com.au>
Subject: Re: Bullet-Proof or Bullet-Resistant (Was Ariane 5 failure)
Date: 1996/10/08
Date: 1996-10-08T00:00:00+00:00 [thread overview]
Message-ID: <325A0894.FB2@dynamite.com.au> (raw)
In-Reply-To: dewar.844518011@schonberg
Robert Dewar wrote:
> However, to the extent that checks are used to catch programming errors,
> I think that I would prefer that a safety critical system NOT depend on
> such devices. A programming error in a checks on program may indeed result
> in a constraint error, but it may also cause the plane to dive into the sea
> without raising a constraint error.
A good point. Unless you use multiple exception handlers at all levels
of the program, it might be better to leave the bug to fester. I guess
you've really got to know what you're doing. Fortunately the concept of
making sure exceptions are trapped everywhere is simple.
> I find the second outcome here unacceptable, so the methodology must simply
> prevent such errors completely. Indeed if you look at safety critical
> subsets for Ada they often omit exceptions precisely because of this
> consideration. After all exceptions make the language and compiler more
> complex, and that itself may introduce concerns at the safety critical
> level.
I don't believe in bug-free code. Even if it is bug-free, there's always
the miniscule chance of hardware and soft failures. Now I'm not saying
that error-trapping will save you every time from every failure: but a
"layered defence" of 40 layers, each of which only catches 50% of
errors, is one heck of a lot more effective than one layer that works
99.99999% of the time.
> Note also that exceptions are a double edged sword. An exception that is
> not handled properly can be much worse than no exception at all.
Concur.
> For example, a low priority task may cause an overflow. If ignored, an
> unimportant result is simply wrong. if not ignored, the handoling of the
> exception mayh cause that low priority task to overrun its CPU slice, and
> cause chaos elsewhere.
And not handling it may cause the same thing, or even violate memory
constraints etc. No Handling means no chance of tolerating such an
error: The ability to handle PLUS someone who knows how to use
exceptions means there is such a chance.
> As Ken says, checks are not a magic wand. They are a powerful tool, but
> like any tool, subject to abuse.
Concur. My conclusion though is that checks are better than no-checks;
even if the person using them is realtively incompetent. Trouble is, I
only have anecdotal evidence of this, not a proper study.
---------------------- <> <> How doth the little Crocodile
| Alan & Carmel Brain| xxxxx Improve his shining tail?
| Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
---------------------- o OO*O^^^^O*OO o oo oo oo oo
By pulling Maerklin Wagons, in 1/220 Scale
next prev parent reply other threads:[~1996-10-08 0:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-10-01 0:00 Ariane 5 failure Marin David Condic, 407.796.8997, M/S 731-93
1996-10-02 0:00 ` Matthew Heaney
1996-10-04 0:00 ` Ken Garlington
1996-10-05 0:00 ` Robert Dewar
1996-10-06 0:00 ` Keith Thompson
1996-10-08 0:00 ` Alan Brain [this message]
1996-10-10 0:00 ` Ken Garlington
1996-10-14 0:00 ` Matthew Heaney
1996-10-15 0:00 ` Robert Dewar
1996-10-16 0:00 ` Ken Garlington
1996-10-18 0:00 ` Keith Thompson
1996-10-18 0:00 ` Samuel T. Harris
1996-10-21 0:00 ` Ken Garlington
1996-10-18 0:00 ` Ken Garlington
1996-10-23 0:00 ` robin
1996-10-02 0:00 ` Robert I. Eachus
1996-10-02 0:00 ` Ken Garlington
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox