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: 1094ba,9f0bf354542633fd X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public From: Niklas Holsti Subject: Re: Fortran or Ada? Date: 1998/10/03 Message-ID: <36164A60.FA563BB0@icon.fi>#1/1 X-Deja-AN: 397388174 Content-Transfer-Encoding: 7bit References: <36068E73.F0398C54@meca.polymtl.ca> <6u8r5o$aa4$1@nnrp1.dejanews.com> <360A3446.8AD84137@lmco.com> <6udre0$ha1$1@nnrp1.dejanews.com> <19980925.185359.250@yktvmv.watson.ibm.com> <6uifdr$dog$1@nnrp1.dejanews.com> <19980928.184428.604@yktvmv.watson.ibm.com> <19980929.214309.386@yktvmv.watson.ibm.com> <3615E297.57D3ED15@icon.fi> <6v5116$hr4$1@newnews.nl.uu.net> Content-Type: text/plain; charset=us-ascii Organization: Sonera Corporation News Service Mime-Version: 1.0 Newsgroups: comp.lang.fortran,comp.lang.ada Date: 1998-10-03T00:00:00+00:00 List-Id: Toon Moene wrote: > > Niklas Holsti wrote: [ snip ] > > If the interpretation is wrong, and Ada exceptions were used, in my view > > the fault was in the poor specification and careless reuse rather than > > in the Ada exception mechanism, which did what it was asked to do. > > No. The problem is in the expectation of Ada programmers that software > errors should be handled the same as hardware errors, by trapping them via a > software trap handler specified by the programmer. Software errors should be > handled by careful, defensive programming, not CYA. I think this "expectation" is reasonable, when recovery is possible by the software itself. In the Ariane-501, the attempted recovery was to switch to a backup system with identical software, which of course is unlikely to work for a software design error of this type. This error-handling policy was imposed on the programmers, as the report makes clear. It is not clear what the programmers would have chosen to do. Of course I agree that defensive programming is useful, but when resources are limited, so must the defenses be; in the Ariane 4, the decision to leave the problematic conversion "undefended" was safe and contributed to meeting the resource constraints. In fact, I would class exception handling as one type of defensive programming, and a very good one, too. (Note that in Ada, it is easy to define local exception handling, for a single statement if need be, instead of relying on a global trap handler which has little knowledge of the context of the problem.) > I believe I even recall that a remark like this is in the report. Perhaps it was somewhere in the following quotes: "It was the decision to cease the processor operation which finally proved fatal. [ ... ] The reason behind this drastic action lies in the culture within the Ariane programme of only addressing random hardware failures. >From this point of view exception - or error - handling mechanisms are designed for a random hardware failure which can quite rationally be handled by a backup system. [ ... ] There is reason for concern that a software exception should be allowed, or even required, to cause a processor to halt while handling mission-critical equipment. [ ... ] The exception was detected, but inappropriately handled because the view had been taken that software should be considered correct until it is shown to be at fault. The Board has reason to believe that this view is also accepted in other areas of Ariane 5 software design. The Board is in favour of the opposite view, that software should be assumed to be faulty until applying the currently accepted best practice methods can demonstrate that it is correct." I think the report criticises the assumption that a trap ("exception") indicated hardware failure rather than software failure. I don't see any criticism of software exception-handling as such, just a suggestion that the most likely cause of a software exception is a software fault, with which I agree. > > -- > Toon Moene (mailto:toon@moene.indiv.nluug.nl) > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > Phone: +31 346 214290; Fax: +31 346 214286 > g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com Niklas Holsti Space Systems Finland Ltd.