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

Question

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

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

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

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

Answer 1

Microsoft Команда шаблонов и практик проделали хорошую работу по включению лучших практик управления исключениями в корпоративную библиотеку. Прикладной блок обработки исключений

Если бы я не использовал корпоративную библиотеку, я высоко рекомендую вам прочитать их документацию.Команда 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

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

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

Answer 5

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

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

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

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

и т. д.и т. д.

Не существует универсального решения для обработки исключений.

Answer 6

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

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