Wouter van Ooijen wrote:

>> Among other things, we included lots of sanity checks internally so that
>> any inconsistency found, no matter how small, would lock the instrument
>> up and display an error code with a message to call me and tell me
>> exactly what this said, that I could trace this to a specific line of
>> code. Those mostly served to show us the mistakes before we ever
>> shipped the first instrument.  But they also allowed me to precisely
>> diagnose and correct an error found by a customer thousands of miles
>> away.
> 
> Good practice indeed, but how do you apply that to a space shuttle in
> descent? For one thing, AFAIK a cell phone does not work at the critical
> moments :(

I think the point of this technique is to avoid (or disable) all sorts of
"defensive" programming techniques during debugging and testing. Many
programmers start out writing code that handles "odd" situations
"gracefully" -- without thinking that during debugging and testing, any
such odd situation should not be handled "gracefully" but rather be at
least logged as error, or stop the whole thing (safely) right there and
"request" to be fixed.

Of course, once you ship this for real use, these "odd" things should
actually be handled "gracefully" (at least safely). It would still be good
to log them, but in embedded systems that's often quite limited :)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist