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: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,f96f757d5586710a X-Google-Attributes: gid101deb,public From: Ken Garlington Subject: Re: Ariane 5 - not an exception? Date: 1996/08/02 Message-ID: <3201D8EC.45E4@lmtas.lmco.com>#1/1 X-Deja-AN: 171584559 references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <31FE35BC.1A0D@sanders.lockheed.com> <838805582snz@nezumi.demon.co.uk> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 x-mailer: Mozilla 2.02 (Macintosh; I; 68K) Date: 1996-08-02T00:00:00+00:00 List-Id: Martin Tom Brown wrote: > > Instead, as is common practice in the safety-critical world, local exception > > handlers are > > frequently banned and a global 'shut it all down' handler is the only stop gap > > measure. > > This is an interesting insight. At least in my experience, the statement is true but incomplete. One approach to safety-critical systems is to write the software so as to _avoid_ exceptions. For example, based on what I've read on the SRI exception, the precision of the 16-bit conversion might have been set such that any 64-bit value would reliably be convertable to the 16-bit field. Other options include saturation arithmetic or explicit checks (vs. Ada implicit checks). Of course, just avoiding the exception is not enough. The alternative chosen has to be capable of meeting the mission requirements. If the software design is judged to be sufficiently reliable, and _sufficient_ analysis is done to show that input data cannot cause an exception, then the remaining exception possibilities are things such as hardware failures. In this case, there may not be an adequate internal response, and shutting down _with an appropriate failure indication_ may be the best choice, if continued operation might cause adverse system impacts. For example, if a system fails such that it is saturating a communications channel with garbage data, you may want the system to shut down so that other communications can continue. > > > Unbelievably the rationale for disallowing local handlers is because they make > > it difficult to > > verify complete code coverage since they are only executed in the case of > > exceptional conditions > > I can see there is a point there, OTOH perhaps there is something wrong > with a test philosophy that don't attempt to push the envelope of valid > data to find what happens if ... > Designing test data to execute each and every path is part of the game. Again, this isn't exactly the issue, in my experience. Whether you have exception handlers or not, you want to test (as much as practical) the full "envelope" of data inputs -- valid and invalid. However, each time code is added to the system, you have to test the functionality and structure of that added code. If that code is not shown to add sufficient value, then you are diverting resoruces from analyzing and testing improtant code to test the less-important code. If you can show that an exception cannot be raised at a certain point, this is sometimes a more effective use of resources than adding code to catch the exception. Of course, whether you do the analysis, or add code, you have to do the engineering correctly. In the Ariane 5 case, this didn't happen. > > Regards, > -- > Martin Brown __ CIS: 71651,470 > Scientific Software Consultancy /^,,)__/ -- LMTAS - "Our Brand Means Quality"