Al registrar cuando es un error fatal?


En marcos de registro como log4j y log4net, 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 en la que siempre he sido tímido fue clasificar mi tala como "Fatal".

¿Qué tipo de errores son tan graves que deberían clasificarse como fatales? Si bien esto es un poco impulsado por el caso, ¿cuáles son algunas de las reglas de oro que se utilizan al decidir entre el registro de un excepción como fatal o simplemente error?

Author: Jason Whitehorn, 2008-11-24

4 answers

Considero que los errores fatales son cuando su aplicación no puede hacer más trabajo útil. Los errores no fatales son cuando hay un problema, pero su aplicación aún puede continuar funcionando, incluso con un nivel reducido de funcionalidad o rendimiento.

Ejemplos de errores fatales incluyen:

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

Los errores no fatales incluirían:

  • Un servidor donde una sola sesión falla por alguna razón, pero aún puede dar servicio 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.
 35
Author: paxdiablo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-24 03:45:05

Un error es Fatal si falta algo o ocurre una situación para la cual la aplicación simplemente no puede continuar. Los ejemplos posibles son una configuración requerida que falta.archivo o cuando una excepción 'burbujea' y es atrapada por un controlador de excepciones no manejado

 6
Author: Mitch Wheat,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-24 03:34:58

Usaría fatal si mi siguiente paso es que la aplicación termine, o simplemente no haga más 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 que sucedió.

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

Si tengo múltiples subprocesos de servicio activados por un subproceso principal y uno de ellos falla debido a alguna entrada incorrecta pero la aplicación todavía puede servir nuevas solicitudes, no lo considero fatal.

 1
Author: Uri,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-24 03:39:34

Para hacer esta respuesta corta y dulce, si su aplicación se bloquea, lo 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 impide que su aplicación se ejecute correctamente y afecta al usuario, lo clasificaría como un error fatal.

Pero la forma más importante de clasificar los errores es seguir consistentemente una regla general como la regla 69 en la codificación en C++ de Normas :

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

 1
Author: kevindaub,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-24 03:41:41