Another "funny incident from life" made me a little nervous.
The program we support has two windows: the main graphical one and the auxiliary console window. A console window that is minimized at startup is usually only needed when the system crashes, it displays standard error messages, and you can even invoke an interactive debugger to try to determine the cause of the crash.
However, during operation, it turned out not very convenient. The fact is that if the application is removed during a crash, then, of course, the graphical window disappears, and the user, at least, can immediately see that the entire system has crashed. The truth and information about the system crash also disappears with the simultaneous closing of the console window. But if the control is intercepted by the debugger in the console (minimized by default) window, the graphic image on the screen "freezes" and at a quick glance it may seem that it is still working. There have been cases of misleading the user with such a picture. In the end, a compromise was found: upon exclusion, the program is still removed, but all information displayed in the console window is also duplicated in the log file.
In our programming system, it is so easy to do, because in the system library, before each output of the next byte of a standard message to the standard console, there is a check: is there a user subroutine that needs to be called each time before the next byte is output? If there is, it is called with a single parameter, this very byte.
Therefore, it is enough just to write a small subroutine that outputs its input byte parameter to the log, as all error messages sent to the console will be automatically duplicated in the log.
Thus, the user will not be deceived by an irrelevant picture, and we will get traces of the system crash in our only log.
, , , - «» , « » . , «», .
, Windows . , ! Windows - (« ?»), , . , Windows ! .
, .. . , - , . , , . , . .. , , . , , « ».
, - .
Well, and then the "recursive descent" began - each attempt to write the exception "recursive access to the file" caused another similar exception because it again tried to write to the log at the time of another log entry, and so on. until the stack is physically exhausted and Windows clears the task with a fatal error message.
The moral is simple: mistakes can be different, including even funny ones, like this one. And, most importantly, recursion is not only a beautiful example of calculating factorial in textbooks, but also sometimes a consequence of ill-considered actions, which can manifest itself in the most unexpected way. After all, the decision to write information about the exception to a file seemed simple, successful, and by no means recursive. But the reality turned out to be different.