Otro "incidente gracioso de la vida" me puso un poco nervioso.
El programa que apoyamos tiene dos ventanas: la principal gráfica y la ventana auxiliar de la consola. Una ventana de consola que se minimiza al inicio generalmente solo se necesita cuando el sistema falla, muestra mensajes de error estándar e incluso puede invocar un depurador interactivo para tratar de determinar la causa del bloqueo.
Sin embargo, durante la operación, resultó no muy conveniente. El hecho es que si la aplicación se elimina durante un bloqueo, entonces, por supuesto, la ventana gráfica desaparece y el usuario, al menos, puede ver inmediatamente que todo el sistema se ha derrumbado. La verdad y la información sobre el bloqueo del sistema también desaparece con el cierre simultáneo de la ventana de la consola. Pero si el control es interceptado por el depurador en la ventana de la consola (minimizada por defecto), la imagen gráfica en la pantalla se "congela" y de un vistazo rápido puede parecer que todavía está funcionando. Ha habido casos de engañar al usuario con una imagen de este tipo. Al final, se encontró un compromiso: tras la exclusión, el programa aún se elimina, pero toda la información que se muestra en la ventana de la consola también se duplica en el archivo de registro.
En nuestro sistema de programación, es muy fácil de hacer, porque en la biblioteca del sistema, antes de cada salida del siguiente byte del mensaje estándar a la consola estándar, hay una verificación: ¿hay una subrutina de usuario que deba llamarse cada tiempo antes de la siguiente salida del byte? Si lo hay, se llama con un solo parámetro, este mismo byte.
Por lo tanto, basta con escribir una pequeña subrutina que envíe su parámetro de byte de entrada al registro, ya que todos los mensajes de error enviados a la consola se duplicarán automáticamente en el registro.
Por lo tanto, el usuario no se dejará engañar por una imagen irrelevante y obtendremos rastros del bloqueo del sistema en nuestro único registro.
, , , - «» , « » . , «», .
, Windows . , ! Windows - (« ?»), , . , Windows ! .
, .. . , - , . , , . , . .. , , . , , « ».
, - .
Bueno, entonces comenzó el "descenso recursivo": cada intento de escribir una excepción "acceso recursivo a un archivo" provocó otra excepción similar porque nuevamente intentó escribir en el registro en el momento de otra entrada de registro, y así sucesivamente. hasta que la pila se agote físicamente y Windows borre la tarea con un mensaje de error fatal.
La moraleja es simple: los errores pueden ser diferentes, incluso divertidos, como este. Y, lo que es más importante, la recursividad no solo es un hermoso ejemplo de cálculo factorial en los libros de texto, sino que a veces también es una consecuencia de acciones mal consideradas, que pueden manifestarse de la manera más inesperada. Después de todo, la decisión de escribir información sobre la excepción en un archivo parecía simple, exitosa y de ninguna manera recursiva. Pero la realidad resultó ser diferente.