2008-11-24 10 views
24

En marcos de registro como log4j & 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 que siempre he sido tímida fue clasificar mi registro como "Fatal".¿Cuándo iniciar sesión cuando es un error 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?

Respuesta

30

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.

Ejemplos de errores fatales incluyen:

  • la falta de espacio en disco en el dispositivo de registro y usted está obligado a mantener el registro.
  • 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 en el que una sola sesión falla por alguna razón, pero todavía se puede dar servicio a otros clientes.
  • Un error intermitente, como pérdida de sesión, si se puede establecer una nueva sesión.
  • Falta información de configuración si se puede usar un valor predeterminado.
+0

La pérdida de conectividad de red puede no ser fatal. Puede ser temporal. –

+0

Me refiero a la pérdida total como "no recuperable" o "demoró demasiado para recuperar", razón por la cual los errores no fatales incluyen la versión intermitente. – paxdiablo

+0

Buena respuesta, pero una cosa: ¿cómo puede una aplicación determinar fácilmente si una pérdida de conectividad de red es temporal o fatal? – vikingsteve

6

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

1

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 un 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.

1

Para que esta respuesta sea corta y dulce, si su aplicación falla, 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 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 clasificar los errores es seguir constantemente una regla de oro, como el artículo 69 de C++ Coding Standards:

"Desarrollar una política de gestión de errores práctica, coherente y racional a principios de diseño, y luego mantente firme ".

+0

Si la aplicación se ha bloqueado, ¡es un poco tarde para registrar el hecho! –

+1

Sin embargo, podría registrar cierta información sobre el bloqueo. – kevindaub

Cuestiones relacionadas