Eu recomendo encerrar a chamada para Elmah em uma classe de wrapper simples.
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
}
}
}
Em seguida, basta chamá-lo sempre que precisar registrar um erro.
try {
...
}
catch (Exception ex)
{
// log this and continue
ErrorLog.LogError(ex, "Error sending email for order " + orderID);
}
Isso tem os seguintes benefícios:
- Você não precisa se lembrar dessa sintaxe levemente arcaica da chamada Elmah
- Se você possui muitas DLLs, não precisa fazer referência a Elmah Core a partir de cada uma delas - basta colocar isso na sua própria DLL do 'Sistema'.
- Se você precisar fazer algum tratamento especial ou apenas desejar colocar um ponto de interrupção para depurar erros, você tem tudo em um só lugar.
- Se você se afastar de Elmah, poderá mudar de lugar.
- Se você possui um log de erro herdado, você deseja reter (por acaso, tenho um mecanismo simples de log de erro vinculado a algumas UIs que não tenho tempo para remover imediatamente).
Nota: eu adicionei uma propriedade 'contextualMessage' para informações contextuais. Você pode omitir isso, se preferir, mas acho muito útil. O Elmah desembrulha automaticamente as exceções para que a exceção subjacente ainda seja relatada no log, mas o contextualMessage ficará visível quando você clicar nele.