Re: Ariane 5 failure

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

Matthew Heaney wrote:
> 
> As you stated, exceptions are only a tool.  They don't replace the need for
> (mental) reasoning about the correctness of my program, nor should they be
> used to guard against sloppy programming.  Exceptions don't correct the
> problem for you, but at least they let you know that a problem exists.
> 
> And in spite of all the efforts of the Ariane 5 developers, a problem did
> exist, significant enough to cause mission failure.  Don't you think an
> exception was justified in this case?

Not necessarily. Keep in mind that an exception _was_ raised -- a predefined 
exception (Operand_Error according to the report). There was sufficient telemetry 
to determine where the error occured (obviously, otherwise we wouldn't know what 
happened!). If the real Ariane 5 trajectory had been tested in an integrated 
laboratory enviroment, then (assuming the environment was realistic enough to 
trigger the problem), the fault would have been seen (and presumably analyzed and 
fixed) prior to launch. So, the issue is not the addition of a user-defined 
exception to find the error -- the issue is the addition of a new exception 
_handler_ to _recover_ from the error in flight.

Assuming that a new exception _handler_ had been added, then it _might_ have made 
a difference. If it did nothing more than the system exception handler (shutting 
down the channel), then the only potential advantage of the exception _handler_ 
might have been to allow fault isolation to happen faster (e.g. if the exception 
were logged in some manner). This assumes that either the exception message was 
sent out with the telemetry, or else the on-board fault logging survived the 
crash. On the other hand, if it had shut down just the alignment function, then 
it might have saved the system. Without more knowledge about the IRS 
architecture, there's no way to say.

> Yes, I agree that there may be times when you don't need any sophisticated
> exception handling, and you could safely turn checks off.  But surely there
> are important sections of code, say for a critical algorithm, that justify
> the use of checks.
> 
> Believe me, I would love to write a software system that I knew were
> (formally) correct and didn't require run-time checks.  But I am not able
> to build that system today.  So what should I do?
> 
> Though I may be the most practiced walker of tightropes, I still like
> having that safety net underneath me.

Just make sure that your safety net isn't lying directly on the ground. Without 
the use of a frame (exception handlers that actually do the right thing to 
recover the system), you'll find the landing is just as hard with or without the 
net!

You might also want to make sure that the net isn't suspended so high that you're 
walking _below_ it, or even worse that you hit your head on the net and it knocks 
you off the rope (just to stretch this analogy a bit further). In other words, a 
complex exception handling structure might actually _detract_ from the 
reliability of your system. There is some merit to the Keep It Simple, Stupid 
principle.

> 
> -matt
> 
> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> mheaney@ni.net
> (818) 985-1271

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com