В моих приложениях asp.net я обычно использовал обработчик глобальных событий Application_Error для регистрации ошибки и перенаправления пользователя на удобную страницу ошибок.
Однако я читал о ELMAH, и, хотя это кажется интересным, Application_Error кажется более простым.
Я читал другие вопросы, в которых люди, включая меня, предлагали так или иначе. Что мне интересно, если есть какая-то значительная польза от использования одного над другим и почему?
Elmah - фантастический проект, и мы используем его для всех наших приложений ASP.NET. Он не только регистрирует необработанные ошибки для вас, но и захватывает всю исходную страницу, которую пользователь видел, которая содержит много деталей для вас.
У него есть поддержка по электронной почте, RSS-каналы (как детализированные, так и дайджест) и привлекательная консоль.
Для 3-х строк в конфигурации и для ссылки dll я бы сказал, что slam dunk.
Я предполагаю, что основным недостатком ELMAH является то, что он может быть излишним для того, что вам нужно. Если он регистрирует и хранит больше информации, чем в вашей собственной реализации, это лишние накладные расходы на хранение и обработку. Вам также необходимо подумать о том, как вы обеспечиваете доступ к консоли ELMAH, поскольку эти сведения о подробностях могут содержать сочные детали вашего приложения (это не должно быть сложно, но это беспокоит, что у вас не было раньше).
С другой стороны, ваша собственная реализация, вероятно, вырастет регистрировать все, что дополнительную информацию, как только вы решили, что некоторая упрямая ошибка требует, и вы действительно заботитесь о бритье доли секунды от времени, которое требуется для ошибки страницу для отображения? Скорее всего, вы в конечном итоге создадите свою собственную версию ELMAH, поэтому почему бы просто не использовать ELMAH и не сэкономить время.
Я бы порекомендовал, чтобы, если вы хотите написать собственное ведение журнала ошибок, а не использовать ELMAH, вы по крайней мере поместите его в модуль, а не прямо в Application_Error в global.asax. Просто подпишитесь на событие "Ошибка" в модуле Init method, и вы можете легко повторно использовать код обработки ошибок в другом приложении с помощью строки в web.config.
Я также считаю полезным обращаться с любыми журналами исключений через мониторинг работоспособности ASP.NET. Это упрощает управление типом и уровнем ведения журнала в web.config, а также позволяет регистрировать исключения, которые были обработаны в try... catch, не доходя до Application_Error. Создайте собственный класс HandledExceptionEvent, который расширяет WebRequestErrorEvent, и вы можете создавать и поднимать эти события в любом блоке catch, где вам действительно хотелось бы знать, что исключение произошло даже при том, что оно было обработано.