Я рекомендую завершити дзвінок до Elmah у власному власному класі обгортки.
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
}
}
}
Тоді просто зателефонуйте, коли вам потрібно буде зареєструвати помилку.
try {
...
}
catch (Exception ex)
{
// log this and continue
ErrorLog.LogError(ex, "Error sending email for order " + orderID);
}
Це має такі переваги:
- Вам не потрібно пам’ятати цей злегка архаїчний синтаксис виклику Elmah
- Якщо у вас багато DLL-файлів, вам не потрібно посилатися на Elmah Core з кожного окремого - і просто покладіть це у свою власну «System» DLL.
- Якщо вам коли-небудь потрібно зробити якесь спеціальне оброблення або просто хочете поставити точку перелому для налагодження помилок, у вас це все в одному місці.
- Якщо ви коли-небудь відійдете від Elmah, ви можете просто змінити одне місце.
- Якщо у вас є застарілий журнал помилок, який ви хочете зберегти (у мене просто трапляється простий механізм реєстрації помилок, який пов'язаний з деякими інтерфейсами, які я не маю часу видалити).
Примітка. Я додав властивість "контекстуальне повідомлення" для контекстної інформації. Ви можете пропустити це, якщо хочете, але я вважаю це дуже корисним. Elmah автоматично розгортає винятки, тому базовий виняток все ще буде повідомлятися у журналі, але контекстуальне повідомлення буде видно при натисканні на нього.