🚀 go-pugleaf

In article <DG8y40.BMz@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
>In article <45cj8d$red@ixnews3.ix.netcom.com>,
>Mike Rubenstein <miker3@ix.netcom.com> wrote:
>>	Finally, it is absurd to make elaborate security checks on debugging 
>>	runs, when no trust is put in the results, and then remove them in 
>>	production runs, when an erroneous result could be expensive or 
>>	disasterous.  What would we think of a sailing enthusiast who wears 
>>	his life-jacket when training on dry land but takes it off as soon as 
>>	he goes to sea>
>>
>>From C, A, R, Hoare in "Hints on programming language design" in 
>
>The analogy is bogus, IMHO.  Constraint checks don't save lives in the
>same way as life jackets.  If the program gets Constraint_Error, what is
>the pilot of the airplane supposed to do?!

Um, if your in a bi-plane (made of bubble gum - like all too much software)
you can send the wing walker out to fix it before you run out of gas.......

Getting back to reality, Ive seen very complex systems built with no error
detection capability, and when a problem occurs with a frequency of once a
week, its a nightmare to debug.  If the application traps the error, and
leaves behind a fairly detailed image of its state when the error occured,
you can save literally weeks of debug time.

There is also a data recovery issue that falls out of a data verification
philosophy..  We had a document written with a very popular Word processor,
and due to some kind of bug, that application was no longer able to read
the file it had written.  Worse, it would outright crash rather than report
an error, and (what would be most desirable) give you what it was able to
read of the file so it could be transcribed to another file.

>Constraint checks just give the programmer a better idea of where to
>start debugging.  So, IMHO, turning checks on during debugging, and off
>(if necessary for speed), during production runs, makes perfect sense to
>me.  Note the "if necessary".  Real-time systems care about time.  If
>checking code is fast enough (and a good compiler will remove most
>checks), then sure, leave it turned on.  But don't be fooled into
>thinking that will make the system work properly in the presence of
>bugs.

Agreed.  But it can tell you that something went wrong, which is almost
always better than trusting the results blindly.  I still here about how
parity errors never happen, and yet I still see them from time to time.
Id rather have to reenter a few numbers in the financials spreadsheet
than have to find out three weeks later that somethings wrong, and figure
out which bit got flipped.  It still doesnt help with coding errors (ie
the lore of the space probe and DO2I...)

>- Bob

-Steve
-- 
--------------------
When all you own is a hammer, every problem is a nail.  Too
many folks grew up with nothing more than a hammer named U**X...