On 5/31/12 6:16 PM, Walter Bright wrote:
On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
On 31.05.2012 13:06, deadalnix wrote:
This is called failing gracefully. And this highly recommended, and you
KNOW that the system will fail at some point.
Exactly. + The point I tried to argue but it was apparently lost:
doing stack unwinding and cleanup on most Errors (some Errors like stack
overflow might not recoverable) is the best thing to do.
This is all based on the assumption that the program is still in a valid
state after an assert fail, and so any code executed after that and the
data it relies on is in a workable state.
This is a completely wrong assumption.
It might be ok if the program is not critical and has no control over
important things like delivering insulin, executing million dollar
trades, or adjusting the coolant levels in a nuclear reactor.
If the code controls anything that matters, then it is not the best
thing to do, not at all.
The right thing to do is to take the shortest path to stopping the
program. A critical system would be monitoring those programs, and will
restart them if they so fail, or will engage the backup system.
[When I worked on flight critical airplane systems, the only acceptable
response for a self-detected fault was to IMMEDIATELY stop the system,
physically DISENGAGE it from the flight controls, and inform the pilot.]
I wonder how we could work into this enthusiasm fixing bugs created by
comparing enumerated values of distinct types...
It did happen in a program of mine to confuse a UserID with a CityID. If
the corrupt CityID would be subsequently entered into the navigation
system of an airplane, it would lead the airplane on the wrong path.
Andrei
