From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public From: Alan Brain Subject: Re: Bullet-Proof or Bullet-Resistant (Was Ariane 5 failure) Date: 1996/10/08 Message-ID: <325A0894.FB2@dynamite.com.au>#1/1 X-Deja-AN: 187333957 references: <96100111162774@psavax.pwfl.com> <32555A39.E38@lmtas.lmco.com> content-type: text/plain; charset=us-ascii organization: @Home mime-version: 1.0 reply-to: aebrain@dynamite.com.au newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Win16; I) Date: 1996-10-08T00:00:00+00:00 List-Id: 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