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.]
This is perfectly valid when developing such critical systems. But limiting D to effectively only allow developing such particular systems cannot be the appropriate response. There are plenty of other systems that do not operate in such a constrained environment. Jens