Re: Ariane 5 - not an exception?

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

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  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
> Scientific Software Consultancy             /^,,)__/

-- 
LMTAS - "Our Brand Means Quality"