Uno de los problemas habituales en el manejo de excepciones, no directamente relacionado con las mismas, es el registrar información sobre la excepción que se ha producido. El framework de .Net proporciona unas excelentes clases para el diagnostico y generación de un log para nuestra aplicación en el namespace System.Diagnostics, conocido esto, el problema se resume en encontrar el balance justo de información que escribiremos en el log de nuestra aplicación. Este problema tiene difícil solución, y solo un adecuada y consistente política a nivel de proyecto nos permitirá alcanzar el equilibrio adecuado. Esta política, como cualquier otra relacionada con convenciones de codificación debe ser escrita y publicitarse entre los miembros del proyecto. Dicho esto, es importante conocer dos antipatrones habituales.
Log and throw: Logear y relanzar la exception
catch(ApplicationException ex)
{
System.Diagnostics.Trace.WriteLine(«Bla bla bla»);
throw ex;
}
o
catch(ApplicationException ex)
{
System.Diagnostics.Trace.WriteLine(«Bla bla bla»);
throw new MyException(«Bla bla bla», ex);
}
Ambos ejemplos son igual de dañinos y por el mismo motivo, encontraremos numerosas trazas para el mismo error, puesto que muy probablemente quien capture la excepción más arriba, también inserte una entrada en el log. La política aquí es clara o bien se logea la información sobre la excepción o bien se relanza pero nunca se deben hacer las dos cosas si queremos contar con un log de aplicación legible.
Multi-Line Messages: Mensajes de log relacionados en multiples lineas.
using System.Diagnotics;
…
Trace.WriteLine(«Error en acceso a fichero»);
WriteLine(«La ruta del fichero es muy larga»);
…
Siempre debemos agrupar los mensajes de logeo lo más posible. Los motivos son dos principalmente, por un lado el rendimiento, puesto que escribir en el archivo de log tiene un coste, y por otro la legibilidad, aunque este no es tan evidente. Viendo el código de ejemplo, se hace evidente que el programador espera que esas dos lineas aparezcan seguidas en archivo de log, pero en una aplicación multihilo (y casí todas las aplicaciones actuales lo son, explicita o implícitamente) , nada garantiza que las lineas se van a escribir seguidas. Podemos terminar encontrando que mensajes realacionados aparecen separados por muchas lineas dentro de nuestro log, lo que sin duda perjudicará gravemente a su legibilidad. Así lo correcto sería:
using System.Diagnotics;
…
Trace.WriteLine(«Error en acceso a ficheronLa ruta del fichero es muy larga»);
…
