tag printable name maker graffiti creator badges design logging error-handling log4net log4j

design - printable - Al iniciar sesión, ¿cuándo es un error fatal?



name tags templates (4)

Considero errores fatales cuando su aplicación no puede hacer ningún trabajo más útil. Los errores no fatales se producen cuando hay un problema, pero la aplicación aún puede seguir funcionando, incluso con un nivel reducido de funcionalidad o rendimiento.

Algunos ejemplos de errores fatales incluyen:

  • Se está quedando sin espacio en el disco en el dispositivo de registro y debe seguir registrando.
  • Pérdida total de conectividad de red en una aplicación de cliente.
  • Falta información de configuración si no se puede usar ningún valor predeterminado.

Los errores no fatales incluirían:

  • Un servidor donde una sola sesión falla por alguna razón, pero todavía puede atender a otros clientes.
  • Un error intermitente, como la sesión perdida, si se puede establecer una nueva sesión.
  • Falta información de configuración si se puede usar un valor predeterminado.

En los marcos de registro como log4j y log4net, usted tiene la capacidad de registrar varios niveles de información. La mayoría de los niveles tienen intenciones obvias (como lo que es un registro de "depuración" frente a un "error"). Sin embargo, una cosa que siempre he sido tímida fue clasificar mi registro como "Fatal".

¿Qué tipo de errores son tan graves que deberían clasificarse como fatales? Si bien esto se basa un poco en el caso, ¿cuáles son algunas de las reglas empíricas que usa al decidir entre registrar una excepción como fatal o simplemente un error?


Para que esta respuesta sea corta y dulce, si tu aplicación falla, la consideraría fatal. Si no puede conectarse a un recurso importante como una base de datos o un servicio requerido, eso sería fatal. En general, diría que si evita que su aplicación se ejecute correctamente y afecte al usuario, la clasificaría como un error fatal.

Pero la forma más importante de clasificar los errores es seguir consistentemente una regla empírica, como la regla 69 en C ++ Coding Standards :

"Desarrolle una política de manejo de errores práctica, consistente y racional al principio del diseño, y luego apéguese a ella".


Un error es fatal si falta algo o se produce una situación para la cual la aplicación simplemente no puede continuar. Algunos ejemplos posibles son la falta de un archivo de configuración requerido o cuando una excepción ''surge'' y es capturada por un manejador de excepciones no controlado


Usaría fatal si mi próximo paso es que la aplicación finalice, o simplemente no haga ningún trabajo posterior. Si la aplicación es parte de un lote o hay varios procesos en ejecución, esto puede ser útil para rastrear lo sucedido.

Si hay una posibilidad de recuperación (por ejemplo, pérdida de la conexión de red con reintentos por un tiempo), no utilizaría una fatal.

Si tengo varios hilos de servicio activados por un hilo principal y uno de ellos falla debido a una entrada incorrecta, pero la aplicación todavía puede atender solicitudes nuevas, no lo considero fatal.