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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a83c46b54bacb7f6 X-Google-Attributes: gid103376,public From: "Mike Silva" Subject: Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co Date: 2000/02/01 Message-ID: <3uFl4.962$dw3.47689@news.wenet.net>#1/1 X-Deja-AN: 580440296 References: <3894A823.92EC75D1@bondtechnologies.com> <874b7r$mj9$1@nnrp1.deja.com> <38967537_1@news.jps.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: news@wenet.net X-Trace: news.wenet.net 949429247 206.169.137.33 (Tue, 01 Feb 2000 10:20:47 PST) NNTP-Posting-Date: Tue, 01 Feb 2000 10:20:47 PST Newsgroups: comp.lang.ada Date: 2000-02-01T00:00:00+00:00 List-Id: Hyman Rosen wrote in message ... >"Pat Rogers" writes: >> Error checking at run-time is still vital, and Ada's checking (if left >> in) can help. >> >> Although it is a common practice in (well-done!) safety-critical >> development to prove that exceptions cannot occur, they still can. The >> obvious cause is radiation-induced hardware errors. The more difficult >> issue, because it is based upon human imperfection, is that of errors in >> the specification. No amount of program proof will circumvent that >> problem. In that case run-time checks can serve to invoke the fault >> tolerance mechanisms, however extensive those may or may not be. >> Clearly some applications can have no fall-back position (the classic >> example is a launched missile) and in those cases there's no point in >> checking. But in those cases in which faults can be tolerated the >> checks are directly helpful. > >But it's exactly that mechanism that led to the Ariane 5 crash. I'd argue that it wasn't the mechanism that was at fault, but the assumptions encoded into the error handler. It's easy to conceive of an error handling strategy that would have let the Ariane survive. > I have >argued before that *not* catching such errors at runtime might be a >better approach, because it's possible that such an error would cause >only slight local effects which would quickly damp out, whereas invoking >error handling leads to massive global effects. Since the nature of an unforseen error is, well, unforseen, it's hard to hard to catch every case. Still, I'd much rather see an effort at handling errors than a blissful disregard of them. Such error handling need not lead to "massive global effects". I think it's noteworthy that the Ariane report did -not- advocate ignoring errors, but rather (picking the two recommendations that seem most appropriate to this discussion): "R6 Wherever technically feasible, consider confining exceptions to tasks and devise backup capabilities." "R8 Reconsider the definition of critical components, taking failures of software origin into account (particularly single point failures)." Mike