Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

["Mike Silva" <mjsilva@jps.net>]

Hyman Rosen wrote in message ...
>"Pat Rogers" <progers@NOclasswideSPAM.com> writes:
>> Error checking at run-time is still vital, and Ada's checking (if left
>> in) can help.
>>
>> Although it is a common practice in (well-done!) safety-critical
>> development to prove that exceptions cannot occur, they still can.  The
>> obvious cause is radiation-induced hardware errors.  The more difficult
>> issue, because it is based upon human imperfection, is that of errors in
>> the specification.  No amount of program proof will circumvent that
>> problem.  In that case run-time checks can serve to invoke the fault
>> tolerance mechanisms, however extensive those may or may not be.
>> Clearly some applications can have no fall-back position (the classic
>> example is a launched missile) and in those cases there's no point in
>> checking.   But in those cases in which faults can be tolerated the
>> checks are directly helpful.
>
>But it's exactly that mechanism that led to the Ariane 5 crash.

I'd argue that it wasn't the mechanism that was at fault, but the
assumptions encoded into the error handler.  It's easy to conceive of an
error handling strategy that would have let the Ariane survive.

> I have
>argued before that *not* catching such errors at runtime might be a
>better approach, because it's possible that such an error would cause
>only slight local effects which would quickly damp out, whereas invoking
>error handling leads to massive global effects.

Since the nature of an unforseen error is, well, unforseen, it's hard to
hard to catch every case.  Still, I'd much rather see an effort at handling
errors than a blissful disregard of them.  Such error handling need not lead
to "massive global effects".  I think it's noteworthy that the Ariane report
did -not- advocate ignoring errors, but rather (picking the two
recommendations that seem most appropriate to this discussion):

"R6 Wherever technically feasible, consider confining exceptions to tasks
and devise backup capabilities."

"R8 Reconsider the definition of critical components, taking failures of
software origin into account (particularly single point failures)."

Mike