Subject: Re: dealing with errors (was: "Programming is FUN again")
From: Erik Naggum <>
Date: 1998/03/26
Newsgroups: comp.lang.scheme,comp.lang.lisp
Message-ID: <>

* Brent A Ellingson
| In other words, why the hell did the equipment test for the exception if
| it didn't know what to do with it, except crash and destroy the rocket?
| Had it not tested for the exception on the non-critical code, the rocket
| probably would not have failed.

  it is amazing that the view that "don't test for errors you don't know
  how to handle" is _still_ possible in the light of that report, but I
  guess that's the way with _beliefs_.  I cannot fathom how people will
  read all the contradictory evidence they can find and still end up
  believing in some braindamaged myths.

  the problem is: the equipment did _not_ test for the exception.  the
  exception was allowed to propagate unchecked until the "crash-and-burn"
  exception handler took care of it.  this could be viewed as silly, but
  the report clearly states why this was sound design: unhandled exceptions
  should be really serious and should indicate random hardware failure.

  the _unsound_ design was not in the exception handling at all, it was in
  allowing old code from Ariane 4 still run in Ariane 5, notably code that
  should run for a while into the launch sequence on Ariane 4 because it
  would enable shorter re-launch cycles -- which was not necessary at all
  on Ariane 5.  the error was thus not in stopping at the wrong time or
  under the wrong conditions -- it was in _running_ code at the wrong time
  and under the wrong conditions.

  "had it not run the bogus code, the rocket would not have failed in it."

  how can you expect to learn from mistakes when you insist that the errors
  you observe are caused by mistakes you think you have _already_ learned
  from, and that others (the dumbass people who use exceptions, in this
  case) are at fault for not learning from?

  rather than "don't test for error you don't know how to handle", I
  propose "don't run code with errors you aren't prepared to handle".

  did you notice how the report had the brilliant insight that we have
  gotten used to think that code is good until proven faulty and that this
  was the major cultural problem pervading the whole design and deployment
  process?  it's high time this insighed could sink into the right people
  and cause more focus on provably correct code and verification.  with the
  extremely arrogant attitude still held by Brent and many others like him,
  we will continue to produce crappy code that crash rockets for millenia
  to come without learning the problem really is: unchecked assumptions!
  religious cult update in light of new scientific discoveries:
  "when we cannot go to the comet, the comet must come to us."