Recomiendo encapsular la llamada a Elmah en una clase de envoltura simple propia.
using Elmah;
public static class ErrorLog
{
/// <summary>
/// Log error to Elmah
/// </summary>
public static void LogError(Exception ex, string contextualMessage=null)
{
try
{
// log error to Elmah
if (contextualMessage != null)
{
// log exception with contextual information that's visible when
// clicking on the error in the Elmah log
var annotatedException = new Exception(contextualMessage, ex);
ErrorSignal.FromCurrentContext().Raise(annotatedException, HttpContext.Current);
}
else
{
ErrorSignal.FromCurrentContext().Raise(ex, HttpContext.Current);
}
// send errors to ErrorWS (my own legacy service)
// using (ErrorWSSoapClient client = new ErrorWSSoapClient())
// {
// client.LogErrors(...);
// }
}
catch (Exception)
{
// uh oh! just keep going
}
}
}
Luego, simplemente llámelo cuando necesite registrar un error.
try {
...
}
catch (Exception ex)
{
// log this and continue
ErrorLog.LogError(ex, "Error sending email for order " + orderID);
}
Esto tiene los siguientes beneficios:
- No necesita recordar esta sintaxis ligeramente arcaica de la llamada de Elmah
- Si tiene muchas DLL, no necesita hacer referencia a Elmah Core de cada una de ellas, y simplemente poner esto en su propia DLL de 'Sistema'.
- Si alguna vez necesita hacer un manejo especial o simplemente quiere poner un punto de interrupción para depurar errores, lo tiene todo en un solo lugar.
- Si alguna vez te alejas de Elmah, puedes cambiar un lugar.
- Si tiene un registro de errores heredado que desea conservar (solo tengo un mecanismo de registro de errores simple que está vinculado a algunas IU que no tengo tiempo de eliminar de inmediato).
Nota: He agregado una propiedad 'contextualMessage' para información contextual. Puede omitir esto si lo prefiere, pero me parece muy útil. Elmah desenvuelve automáticamente las excepciones, por lo que la excepción subyacente aún se informará en el registro, pero el mensaje contextual será visible cuando haga clic en él.