Рекомендации по работе с распространенными ошибками на страницах ASP.NET

Question

Я работаю над веб-приложением ASP.NET.Я внедряю каркас ведения журналов для всего приложения. Веб-приложение

имеет около 7-8 страниц и представляет собой простое веб-приложение с операциями CRUD.

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

1) Добавлены блоки Try ... Catch на уровне доступа к данным и события Click.

2) При обнаружении ошибок,Я распространяю исключения на уровень Globabl.asax и в журнале событий Application_Error регистрирую ошибку в журналах событий и журналах трассировки.

3) После этого в файле Global.asax я перенаправляю на страницу ошибок, чтобыпоказать удобное для пользователя сообщение и ссылку на сбойную страницу.

4) Просто хотел узнать, насколько это хороший подход:

Спасибо, друзья.

Answer 1

Вы действительно обрабатываете исключения в DAL (т. Е. Ведете журнал, пытаетесь это исправить и т. Д.)? Если нет, то попытка catch не имеет смысла, кроме циклов вращения. То же самое относится и к событиям щелчка, но это не плохая практика обработки ошибок в пользовательском интерфейсе, даже если вы по-настоящему ничего с ними не делаете, так как вы будете перенаправлять пользователя со страницы ужасной ошибки на собственное дружеское сообщение .

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

Существует вариант страницы с общей ошибкой, если вы работаете с HTTP-статусами и используете config.

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

Answer 2

Я думаю, вам не нужно использовать Exception Handling. Предположим, у вас есть уровень представления и уровень бизнес-логики / уровень DataAccess.

При появлении ошибки, скажем, в Business Logic, она будет перемещена непосредственно в файл Glogal.asax.cs в Event_Error Event, не возвращаясь к вызывающей функции. Здесь вы можете войти сообщение об ошибке, как показано ниже ....

HttpContext.Current.Server.GetLastError().InnerException.StackTrace
HttpContext.Current.Server.GetLastError().InnerException.Message
HttpContext.Current.Server.GetLastError().InnerException.Source
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.FullName
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Name
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Namespace

---

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

<customErrors defaultRedirect="ErrorPage.htm" mode="On">
   <error statusCode="404" redirect="ErrorPageNotFound.htm"/>
</customErrors>

Answer 3

Звучит так, будто вы изобретаете колесо здесь. ASP.NET уже включает в себя вещи, которые помогут вам достичь желаемого результата. Если вам не нужна обработка логики для очистки после ошибок, я бы не использовал блоки try try. Просмотрите Обзор мониторинга работоспособности ASP.NET для регистрации ошибок. Что касается представления пользовательской страницы ошибок, см. Как создать пользовательские страницы отчетов об ошибках в ASP.NET с помощью Visual C # .NET .

Answer 4

Почему бы не использовать пользовательские страницы ошибок ASP.NET? Вы можете указать каждую страницу ошибки для каждого кода состояния или указать перенаправление по умолчанию.

Вы можете настроить это в веб-конфигурации, и все готово.

 <customErrors defaultRedirect="GenericError.htm" mode="On">
          <error statusCode="404" redirect="notfound.htm"/>
 </customErrors>

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

http://aspnetresources.com/articles/CustomErrorPages

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