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: Toon Moene <toon@moene.indiv.nluug.nl>
Subject: Re: Fortran or Ada?
Date: 1998/10/03
Message-ID: <6v5t20$ecr$2@newnews.nl.uu.net>#1/1
X-Deja-AN: 397418836
References: <36068E73.F0398C54@meca.polymtl.ca>
     <slrn70dv6k.2qp.gisle@krake.ii.uib.no>
     <m3n27sqhms.fsf@visar.physast.uga.edu> <6u8r5o$aa4$1@nnrp1.dejanews.com>
     <m3zpbq24wq.fsf@visar.physast.uga.edu> <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>
     <wclodius-2909981741110001@clodius.lanl.gov>
 <19980929.214309.386@yktvmv.watson.ibm.com> <3615E297.57D3ED15@icon.fi>
 <6v5116$hr4$1@newnews.nl.uu.net> <36164A60.FA563BB0@icon.fi>
Organization: Moene Computational Physics, Maartensdijk, The Netherlands
Newsgroups: comp.lang.fortran,comp.lang.ada
Date: 1998-10-03T00:00:00+00:00
List-Id: <comp.lang.ada>

Niklas Holsti <nholsti@icon.fi> wrote:

> I wrote:

> > 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.

and you quoted from the report:

<quote>

> [ ... ] 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."

</quote>

> 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.

OK, good point - I was probably reading it in a different way because I am 
not used to thinking of "exceptions" as anything a "user routine" should take 
care of.

In my mind, an exception is a sign that the assumptions behind the 
(physics/mathematics) of your model is wrong, and - even though that pertains 
to a large extent also to rocket ascent - this would not lead to a reasonably 
safe procedure here.

-- 
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