¿Ignorar errores (graves) para mantener vivo el programa?

Question

Una de las cosas principales que quería lograr en mi lenguaje de programación experimental era: Cuando se producen errores (sintaxis, nombre, tipo, etc.) mantener el programa en ejecución, sin importar cuán grave o devastador sea. Sé que esto es probablemente muy malo, pero solo quería algo que no se mata en cada error: . Me parece interesante lo que sucede cuando se produce un error grave pero el programa continúa.

• ¿Este "paradigma" tiene un nombre? Quiero decir esperar para
• ¿Qué tan malo es hacer lo anterior?
• ¿Hay programas en uso por ahí que sólo sigue: "bueno, esto es un error grave, inesperada - pero usted sabe lo que no me importa?"?

Answer 1

En la nomenclatura, se podría decir que el lenguaje exposiciones "terquedad".

estrellarse se prefiere normalmente, porque los programas no deben devolver resultados impredecibles e irrepetibles. En general, ningún resultado es mejor que uno no confiable, especialmente si está haciendo algo crucial para el negocio. Por ejemplo, es mejor que el pedido de un cliente en Amazon no se procese (siempre pueden volver a enviarlo) que entregarle un producto al azar. Algunos errores son verdaderamente irrecuperables, por ejemplo, si el puntero de la instrucción está dañado.

Puede implementar un comportamiento similar en la mayoría de los idiomas modernos con catch all exception handlers.

Answer 2

no sé acerca de un nombre.

¿Qué tan malo es? No lo sé; ¿para qué lo estás usando? Por lo general, es mejor tener un bloqueo que un error silencioso. Los bloqueos son obvios y, por lo general, pueden corregirse, pero es probable que los errores silenciosos pasen inadvertidos, por lo que no importa cuán fáciles sean de corregir.

hay situaciones en las que esto puede ser lo que hay que hacer. He leído acerca de una computadora de control de fuego de la Armada con "barras de batalla" que deshabilitaba las instalaciones de excepción, con el argumento de que mientras corriera podría estar dando buena información, mientras que si no se está ejecutando usted sabe muy bien no lo es En la batalla, con frecuencia sucede que no hacer nada es malo, incluso si no se puede hacer algo particularmente útil.

Answer 3

Para que su programa de proceder, que tendría que tener un estado básico que sabe que es bueno, y luego cada solicitud se procesa independientemente. Por ejemplo:

• Una aplicación cliente/servidor. Las nuevas solicitudes que ingresan al servidor se procesan de manera independiente, y si una solicitud falla de manera catastrófica, el servidor la detecta y pretende que no sucedió, o le informa al cliente que falló.
• Una aplicación local. Hay una forma básica, y todo lo que el usuario intenta hacer se instancia desde allí. Si un proceso falla de manera catastrófica, la instancia de este proceso (tal vez un formulario MDI) se elimina y el usuario queda con su formulario inicial de capa de aplicación, puede volver a intentarlo o hacer otra cosa.

Lo más importante a tener cuidado de si está haciendo esto es que su aplicación debe tener algún núcleo irreductible que es libre de errores, y se encargará de las excepciones no planificados (no es una tarea fácil). Sin mencionar que tragar excepciones inesperadas puede hacer que la solución de problemas/depuración sea miserable, el núcleo irreducible no puede fallar, o de lo contrario fallará toda la aplicación.

Answer 4

Fui con el método de 'topología militar' de manejo de errores.

Los errores se deben clasificar por gravedad, luego se resuelven o se pasan a un superior para su resolución.

Se ordena a una persona privada que limpie el patio de armas con un cepillo de dientes. Se queda sin jabón. Ese es un problema que debería resolver él mismo y no molestar a su superior.

Si el patio de armas tiene un pelotón de soldados enemigos que aterrizan en él, es probablemente algo que debe contarle a sus superiores.

Por favor, dame crédito en la sección 'snark' de tu libro cuando seas rico y famoso.

Answer 5

Asumiendo que es posible determinar que todos los errores de tipo X son stop-show y que todos los errores de tipo Y no lo son. Creo que esto suena bien en la superficie, pero el diablo está en los detalles. En la práctica, no creo que puedas pensar en un solo error que siempre es benigno.

Menciona "Sintaxis, nombre, tipo". Si conoce errores de sintaxis comunes que pueden corregirse de manera objetiva sin causar problemas, compilarlos en la especificación y dejar que el compilador los maneje (en ese punto ya no serían errores de sintaxis). No sé a qué tipo de error trivial se refiere "Nombre". Evitar los errores de tipo es una cuestión de tener un sistema de tipeo dinámico. Nuevamente, esto es parte de la especificación, no del manejo de errores.

Lo que estoy leyendo es que quiere tener una determinada especificación, un compilador versátil que permite escribir la sintaxis de varias maneras y un sistema de tipeo dinámico. Esto es genial y te deseo la mejor de las suertes. Pero no confundas esto con la interpretación de la intencionalidad del codificador y pensando que puedes distinguir un error aceptable de uno perjudicial.

Answer 6

Me parece que estamos hablando de la diferencia entre la corrección y robustez. Un programa altamente robusto sigue funcionando sin importar qué. Un programa altamente correcto solo da salidas correctas. Estas dos cualidades a menudo son diametralmente opuestas y deben equilibrarse entre sí. No hay una forma general de decidir sobre el equilibrio entre los dos. Depende del propósito del programa. Por lo tanto, realmente no hay forma de que un compilador decida inteligentemente cuál debería favorecer.

La programación de la robustez no es necesariamente algo malo. Los controladores de dispositivos, por ejemplo, tienden a ser muy robustos (al menos los buenos). En términos generales, no está bien que un controlador de dispositivo explote ante errores inesperados, ya que esto podría acabar con todo el sistema. Los controladores de dispositivos a menudo interpretan errores "fatales" en la forma "no me importa" que describa. Por ejemplo, si el hardware envía datos dañados, a menudo es suficiente simplemente descartarlo y esperar una nueva muestra.

Answer 7

El enfoque de Erlang parece ser bastante equilibrado. Si un proceso falla, no (idealmente) afectará a los demás.