Обработка исключений в .net веб-приложениях

Question

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

Я прошел тщательное тестирование, проверку и молчаливую молитву, но это плохая программная авария, ожидающая своего появления.

Итак, каковы ваши исключения обработки лучших практик? В частности, где наиболее очевидные / критические места, где следует применять обработку исключений, и места, где это следует учитывать?

Извините за смутный вопрос, но я действительно хочу закрыть книгу по этому вопросу раз и навсегда.

Answer 1

Команда Microsoft Patterns & Practices проделала хорошую работу, включив лучшие практики управления исключениями в Enterprise Library Блок приложения обработки исключений

Если событие не будет использовать Enterprise Library, я настоятельно рекомендую вам прочитать их документацию. Команда P & P описывает общие сценарии и лучшие практики для обработки исключений.

Чтобы начать, я рекомендую прочитать следующие статьи:

• Обработка исключений на MSDN
• Управление исключениями в .NET на MSDN
• Рекомендации по обработке исключений в .NET в CodeProject

Статьи ASP.NET:

• Удобная обработка исключений ASP.NET
• Глобальная обработка исключений с ASP.NET
• Обработка исключений в C # и ASP .Net

Answer 2

Золотое правило с обработкой исключений:

«Поймай только то, что умеешь обращаться»

Я видел слишком много блоков try-catch, где catch ничего не делает, кроме как отбрасывает исключение. Это не добавляет никакой ценности. Тот факт, что вы вызываете метод, который может вызвать исключение, не означает, что вам придется иметь дело с возможным исключением в вызывающем коде. Часто вполне допустимо, чтобы исключения распространялись вверх по стеку вызовов в некоторый другой код, который знает, что делать. В некоторых случаях допустимо распространять исключения вплоть до уровня пользовательского интерфейса, а затем перехватывать и отображать сообщение для пользователя. Может случиться так, что нет лучшего кода, который бы знал, как справиться с ситуацией, и пользователь должен решить, как действовать.

Answer 3

Я рекомендую вам начать с добавления хорошей страницы с ошибкой, которая перехватывает все исключения и печатает несколько менее недружественное сообщение пользователю. Обязательно запишите все доступные сведения об исключении и исправьте его. Сообщите пользователю, что вы сделали это, и дайте ему ссылку на страницу, которая будет (вероятно) работать.

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

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

Answer 4

Начните с глобального обработчика исключений, такого как http://code.google.com/p/elmah/.

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

В качестве примера рассмотрим сайт хостинга фотографий, на котором есть дисковые квоты, лимиты размера файлов, лимиты размеров изображений и т. Д. Для каждой ошибки можно просто указать: «Произошла ошибка. Пожалуйста, повторите попытку». Или вы можете получить подробную обработку ошибок:

• "Ваш файл слишком большой. Максимум Размер файла 5 МБ. "
• "Ваше изображение к большому. Максимальные размеры 1200x1200. "
• "Ваш альбом заполнен. Максимальная емкость хранилища составляет 1 ГБ ".
• "Произошла ошибка с вашим загрузить. Наши хомяки несчастны. Пожалуйста, зайдите позже. "

и т.д.. и т.д.

Нет единого размера, подходящего всем для обработки исключений.

Answer 5

Может быть, больше об обработке исключений в целом, чем в ASP.NET, но:

• Старайтесь ловить исключения как можно ближе к причина как можно более, чтобы вы может записывать (регистрировать) как можно больше информации о возможном исключении.
• Включите некоторую форму, чтобы поймать все, последний обработчик исключений курорта на точки входа в вашу программу. В ASP.NET это может быть Обработчик ошибок уровня приложения.
• Если вы не знаете, как «правильно» обработать исключение, дайте ему всплыть до обработчика catch all, где вы можете рассматривать его как «неожиданное» исключение.
• Используйте методы Try ***** в .NET для таких вещей, как доступ к Толковый словарь. Это помогает избежать серьезных проблемы с производительностью (исключение обработка относительно медленная), если вы бросить несколько исключений, скажем, в цикл.
• Не использовать обработку исключений для контролировать нормальную логику вашего программа, например выход из цикла через оператор броска.

Answer 6

Ну, на самом базовом уровне вы должны обрабатывать событие HttpApplication.Error в файле Global.asax. Это должно регистрировать любое исключение, которое происходит в одном месте, чтобы вы могли просмотреть трассировку стека исключения.

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