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

["Pat Rogers" <progers@NOclasswideSPAM.com>]

"Hyman Rosen" <hymie@prolifics.com> wrote in message
news:t7bt606bro.fsf@calumny.jyacc.com...
> "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.

No.  They treated all exceptions as indication of hardware failures
because they didn't believe
they could happen due to software.  They didn't meaningfully handle the
exception -- they aborted the program!  Since they abused the software
they were reusing (by using it in a different context, in which
exceptions were unavoidable) their assumptions were invalid.

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

A man falls off a very, very tall building.  Halfway down he is heard to
say "This isn't so bad after all!".

Placing one's head in the sand seems a very unhelpful approach.  The
Ariane 5 management made a very bad mistake by doing just that.

--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages