Cuándo registrar la excepción?

Question

try 
{ 
    // Code 
} 
catch (Exception ex) 
{ 
    Logger.Log("Message", ex); 
    throw; 
} 

En el caso de una biblioteca, ¿debería incluso registrar la excepción? ¿Debería lanzarlo y permitir que la aplicación lo logre? Mi preocupación es que si registro la excepción en la biblioteca, habrá muchos duplicados (porque la capa de la biblioteca lo registrará, la capa de la aplicación lo registrará, y cualquier cosa intermedia), pero si no lo registro en el biblioteca, será difícil rastrear errores. ¿Hay mejores prácticas para esto?

Answer 1

No registraría una excepción de la que no iba a hacer nada, es decir, si solo está pasando por un controlador de excepción como en su ejemplo. Como ya lo mencionó, esto agrega mucho ruido que no necesariamente es útil. Es mejor iniciar sesión en el punto en el que realmente está haciendo algo al respecto, o, en el caso de una biblioteca, en el límite donde transita en el código del usuario.

Dicho esto, siempre trato de iniciar sesión en el punto donde estoy lanzando la excepción y la condición que desencadenó la excepción. Esto es mucho más útil para precisar el motivo de la excepción; Además, si la condición que encuentras es lo suficientemente grave como para justificar el lanzamiento de una excepción, yo diría que también garantiza pasar el tiempo del procesador desconectando el 'por qué'.

Answer 2

Debe iniciar sesión y lanzarla para que la aplicación tenga esto disponible para que se registre. En particular, si es una biblioteca, debe iniciar sesión, ya que no debe suponer que la aplicación definitivamente lo registrará (puede o no).

Answer 3

Tiendo a preferir dejar el registro al cliente de nivel más alto, o permitir que el cliente habilite/deshabilite el registro potencialmente proporcionando un TextWriter a la biblioteca a la que la biblioteca debe registrar sus errores/salida en caso de que se esté ejecutando en un entorno donde no tiene permiso para escribir en su registro habitual.

La razón por la que prefiero iniciar sesión en niveles superiores es porque los niveles superiores tienen más información de contexto y pueden conocer formas más apropiadas de informar/registrar estos errores. Dado que las excepciones tienen toda la información de seguimiento de la pila en ellos de todos modos en estos días, no creo que ganes mucho iniciando sesión inmediatamente cuando se produce la excepción. Sin embargo, debe tener cuidado con las excepciones que se convierten en otros tipos de excepciones, de modo que siempre use InnerException si está convirtiendo excepciones a medida que se manejan, a fin de mantener toda la información sobre el origen de un error.

Edit: Por supuesto, esta filosofía solo funciona en entornos donde se cumple mi otra filosofía: nunca ignore las excepciones. Si el cliente o alguna capa intermedia está lanzando excepciones, entonces usted tiene otros problemas y probablemente necesitará por lo menos predeterminar su registro de excepción a algún resultado que se genere, incluso si el cliente es irresponsable.

Answer 4

Las excepciones de registro también pueden ser un método para depurar una aplicación.

Answer 5

Use log4net. Seriamente.

Al utilizar una biblioteca estándar y ubicua, recibe orientación de personas que han pasado mucho tiempo pensando en este problema. La solución es que la mayoría de las bibliotecas de registro tienen varios niveles de registro.

En log4net por ejemplo que puedo hacer

ILog log = LogManager.GetLogger("some logger"); 
log.Debug("some debugging info"); 
log.Info("some message meaningful in the domain"); 
log.Warn("something might be occurring that merits your attention"); 
log.Error("Everything just went to hell") 

El administrador de la aplicación puede entonces establecer diferentes niveles de registro que está interesado en ver. Es posible incluso permitirle cambiar esta configuración en tiempo de ejecución.Como cuestión de hecho, con una sólida biblioteca de registro como log4net puede dirigir diferentes niveles de registro de diferentes fuentes a diferentes appenders. Por ejemplo, puede tener un archivo continuo con todos los mensajes de la última semana almacenados en el disco duro, toda la información, advertencia y mensajes de error que no se originan en la capa de acceso a datos ingresada en una base de datos, y todos los errores enviados a usted por correo electrónico

Creo que lo que describes cae muy claramente bajo el nivel de "depuración".

Puede, por supuesto, implementar niveles de registro por su cuenta, pero si alguien que utiliza su biblioteca está interesado en ver toda la información de depuración, tendrá que aprender su sistema, además de cualquiera que esté usando. Mejor estandarizar.

Así que las mejores prácticas:

1. usar niveles diferentes de registro.
2. No mueva su propio marco de trabajo de registro, use log4net (que realmente es en este día y edad bastante estándar) o al menos entlib logging block de Microsoft.