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: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/04/06 Message-ID: #1/1 X-Deja-AN: 231097739 References: <01bc3603$f9373d40$b280400a@gavinspc> <01bc4021$607eea80$b280400a@gavinspc> <5i3fmr$cgn@gcsin3.geccs.gecm.com> Organization: New York University Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object,comp.programming.threads,comp.software-eng Date: 1997-04-06T00:00:00+00:00 List-Id: Derek said to Colin << >Good. The main point about the Java model, though, is that the compiler >checks that the programmer has at least thought about handling all >exceptions that may be generated in nested calls. This means that the >programmer HAS to think about dealing with error conditions. So, in the >Ariane case, if the precondition existed (as some say it did) the compiler >would have given warnings to the effect that it IF the error occurred, it >would NOT have been handled. Wouldn't this have made the disaster less >likely? No, no and thrice no! >> In fact it is even worse. If there had been systematic assertions in the code, then the assertion that the exception could not possibly arise would have been explicitly built into the software. The assertion, if implemented by runtime code, would of course have failed, but this would have been functionally equivalent to the runtime check that *did* fail. But the source code would have had a very explicit, rather formal looking, gizmo that would have acted to reassure any software person looking over the code. One can imagine the following scenario. "Hey Joe, can't this conversion raise an exception, and as far as I can see that would be disastrous." "Well look at the assertion, I guess the hardware guys know what they are talking about". ... I have seen a number of cases where formalizing error checking, and in particular doing runtime checking have caused problems that would not otherwise be there. Overall, runtime checking is a clear win, but it does have a bit of a dark side, as the Ariane experience showed, and it means that software folks have to be VERY sure that this dark side is properly dealt with, particularly in the context of reuse, where all assumptions, big and small, explicit and implicit, must be carefully revisited. I know it is very tempting when a giant bug occurs with the software written in language X, for all the (not X) advocates to crowd around and see whether their language would have "prevented" the error. Ada folks can't complain too much about this phenomenon, since it has happened the other way round often enough ... Still, often it turns out that the bug is not really language related at all, as in the Ariane case. It may teach us something about software process, and about reuse strategies, but in this particular case we do not learn much about programming language design.