Должен ли я перехватить все мои исключения в global.asax?

Question

Если я просто регистрирую подробности исключений в своем веб-приложении, нужно ли мне включать логику обработки исключений для каждого уровня? Почему бы просто не позволить им скопировать трассировку стека в global.asax и зарегистрировать их там?

Answer 1

Я бы не рекомендовал использовать любую логику обработки исключений в любом слое вашего приложения, кроме случаев, когда:

• Исключение не является фатальным, то есть вы выполняете какое-то действиеможет потребоваться восстановление или
• Приложение должно продолжить работу, а исключение следует «игнорировать».Пример: при проверке в интернет-магазине вам отправляется квитанция по электронной почте.Если это не удается - но другой процесс обработки заказа завершается успешно - пользователю не должна отображаться страница с ошибкой.Здесь мы хотим, чтобы рабочий процесс продолжался, хотя есть исключение.Большинство исключений не попадают в эту категорию.

Конечно, исключения - фатальные они или нет, или их следует «игнорировать» или нет - необходимо регистрировать и уведомлять разработчиков.Лучше всего это обрабатывать с помощью обработчика события Application.Error.Да, это можно сделать в Global.asax, но я думаю, что лучше использовать подход на основе модуля HTTP: Мониторинг состояния или ELMAH .

IЯ написал статью на эту тему, которую я хотел бы порекомендовать вам - Совет по обработке исключений для веб-приложений ASP.NET .Вот краткая статья:

Мой совет по обработке исключений в приложении ASP.NET можно свести к следующим рекомендациям:

(a) Создание и использование значимогонастраиваемая страница ошибки.

(b) В общем, не ловите исключения.Пусть они всплывают до времени выполнения ASP.NET.Некоторые случаи, когда перехват исключения имеет смысл, включают:

• Когда существует вероятный способ восстановления после исключения путем выполнения некоторой альтернативной логики,

• Когда периферийная часть рабочего процесса приложения выдает и исключение, и это исключение не должно сбивать с толку все приложение, и

• Когда вам нужно включить дополнительную информацию с исключением, создав новое исключениеисходное исключение является внутренним исключением.

(c) Записать все исключения в какое-либо постоянное хранилище и использовать электронную почту (или другой носитель) для уведомления разработчиков о возникновении исключения в рабочей среде.,Рассмотрите возможность использования встроенной системы мониторинга работоспособности ELMAH или ASP.NET для облегчения этого процесса.

Answer 2

Исключения должны доходить до любого уровня, который может с ними справиться осмысленно, зная принцип Одиночной ответственности . Например, ваш уровень данных не должен быть инвестирован в ведение журнала.

Событие Application.Error является хорошим местом для обработки всех ошибок: непредвиденных и / или фатальных ошибок, которые не требуют специальной обработки, кроме регистрации / оповещения и перенаправления на страницу ошибки.

Answer 3

Если ваше веб-приложение использует расширения Microsoft AJAX и частичные обратные передачи, вам нужно обрабатывать исключения как минимум в двух местах:

1. Global.asax
2. Обработчик OnAsyncPostBackError вашего ScriptManager

Для получения дополнительной информации о OnAsyncPostBackError, проверьте:

http://msforge.net/blogs/janko/archive/2008/02/13/handling-exceptions-in-asp-net-ajax.aspx

http://msdn.microsoft.com/en-us/library/system.web.ui.scriptmanager.onasyncpostbackerror.aspx

Answer 4

Я говорю, что при глобальном попытайтесь отловить ошибку, которую вы пропустили на логических шагах вашей программы, и перенаправить их на «страницу ошибки» или «страницу не найдена».

Все другие ошибки, которые необязательны, показывают ошибку для пользователя и не требуют ее отправки на страницу ошибки.

Например, на странице с двумя или более различными модулями, если один из них выдает ошибку, просто скрыть ее и показать остальные. Подобные попытки пытаются отлавливать ошибки, когда они возникают, и обрабатывать их наилучшим невизуальным способом для пользователя, если это возможно, регистрировать их и исправлять позже.

Теперь эта ошибка возникает только в одном модуле, вы можете увидеть ее в своем журнале и исправить, но пока вы не сделаете это, пользователь увидит что-то на вашей странице, а не полную страницу ошибки.

Answer 5

Обычно я делаю попытку ... поймать в коде, но вместо того, чтобы войти в ловушку, я передаю сообщение с указанием источника ошибки и т. Д. Затем я использую Elmah для поймать все ошибки и записать их.

Таким образом, вам приходится иметь дело только с регистрацией в одной области и удовлетворять принципу единой ответственности, но у вас есть больше информации для отладки. Это также может быть полезно, когда вы получаете ошибку данных, которая, по-видимому, возникает только у 1 из 500 пользователей.