¿Qué registrar cuando ocurre una excepción?

Question

public void EatDinner(string appetizer, string mainCourse, string dessert) 
{ 
    try 
    { 
     // Code 
    } 
    catch (Exception ex) 
    { 
     Logger.Log("Error in EatDinner", ex); 
     return; 
    } 
} 

Cuando ocurre una excepción en un método específico, ¿qué debería estar registrando?

Veo mucho de lo anterior en el código con el que trabajo. En estos casos, siempre tengo que hablar con la persona que experimentó el error para averiguar qué estaban haciendo, recorrer el código e intentar reproducir el error.

¿Existen mejores prácticas o formas en que puedo minimizar todo este trabajo extra? ¿Debo registrar los parámetros en cada método de esta manera?

Logger.Log("Params: " + appetizer + "," + mainCourse + "," + dessert, ex); 

¿Existe alguna forma mejor de registrar el entorno actual? Si lo hago de esta manera, ¿tendré que escribir todo esto para cada método que tengo en mi aplicación? ¿Existen mejores prácticas en escenarios como este?

Answer 1

Como regla general, me gustaría esforzarme por registrar toda la información necesaria para reproducir el curso de los eventos que conducen a un error. Tenga en cuenta que no necesita necesariamente registrar todo dentro del bloque catch: puede poner (depurar) instrucciones de registro en su código, dentro de métodos llamados, etc. que le permiten seguir lo que estaba sucediendo directamente antes de la excepción. Además, debe incluir información en la propia excepción sobre el síntoma exacto que la causó.

En mi humilde opinión, revisar todo el código para agregar declaraciones de registro puede ser exagerado o, al menos, no rentable en un proyecto de la vida real. En su lugar, se centran en las partes de código más importantes para maximizar los rendimientos de sus esfuerzos. Estas partes del código son típicamente donde ocurren la mayoría de los errores y/o la mayoría de las modificaciones se realizarán. En la práctica, siempre que necesite tocar una parte del código, piense en el registro, revise las declaraciones de registro que ya están allí (si hay alguna), verifique el manejo de excepciones (si hay alguna, veo rutinariamente no solo código como su ejemplo, simplemente traga la excepción capturada, pero incluso los bloques catch vacíos o autogenerados en nuestro código heredado ... todos estos pueden dejar la aplicación en un estado indefinido, que es MALO), y piensa si lo que ya está allí es suficiente para ti para reproducir fallas y entender qué sucedió si ocurre un error. Luego, mejore todo lo que necesite y pueda con un esfuerzo razonable.

También ayuda a discutir este tema con sus compañeros de equipo y tratar de punto un proyecto de convención áspera de cómo registrar eventos, cómo manejar excepciones, etc. Esto podría ahorrar una gran cantidad de tiempo gastado en los insectos que persiguen y/o mejorar el código producido por sus propios compañeros de trabajo :-(

Answer 2

Es un código bastante horrible. Se come la excepción, presumiblemente dejando la aplicación en un estado indefinido. En general, por supuesto, registre la excepción (pero no lo haga) t ajustar cada bit de código en un bloque try), pero luego volver a lanzarlo.

Answer 3

Su marco de trabajo de registro debe capturar la mayor cantidad de contexto para usted, ya que puede. al menos, puede capturar fácilmente la clase en la que se produjo el error. También debe registrar la excepción completa, incluida stacktrace y cualquier excepción interna.

As I answered in your other question debe usar diferentes niveles de registro. Una vez hecho esto, si está utilizando un contenedor de inversión de control, es una tarea bastante simple conectar un interceptor que interceptará todas las llamadas a métodos y si está en modo de depuración, registre la llamada, la marca de tiempo y cualquier parámetro.

Answer 4

Aquí está un example de Rico Mariani (CLR perf) por qué no debe detectar todas las excepciones.Puede ser realmente difícil diagnosticar el problema real.