comp.lang.ada
 help / color / mirror / Atom feed
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




  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