Централизованная обработка ошибок ASP.NET: <customErrors>против Application_Error.Можно ли использовать оба? - PullRequest
Новая
       18

Централизованная обработка ошибок ASP.NET: <customErrors>против Application_Error.Можно ли использовать оба?

4 голосов
/ 29 сентября 2010

В настоящее время мы обрабатываем ошибки через Application_Error в global.asax.vb: 

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    OurLibrary.HandleError(Me)
End Sub

HandleError затем регистрирует ошибку в базе данных, отображает информационное сообщение для пользователя и возвращает правильный код состояния (404 или 500) в зависимости от типа возникшего исключения: 

Public Shared Sub HandleError(httpApp As HttpApplication)
    ''# do some logging
    ...

    ''# show some details about the error and information about how to contact us
    httpApp.Response.Write(...)

    httpApp.Response.StatusCode = 404 or 500
    httpApp.Server.ClearError()
End Sub

Server.ClearError необходимо, поскольку в противном случае запускается обработка ошибок ASP.NET по умолчанию, и отображается пользователь - в зависимости от текущего состояния <customErrors> - либо «желтый экран смерти», либо информационное сообщение. о том, как <customErrors> можно отключить.

Недостаток использования ClearError заключается в том, что я больше не могу использовать <customErrors> для переопределения поведения обработки ошибок - что вызвало немало проблем во время недавней ASP.NET-уязвимости , где рекомендуемый обходной путь был сделан, используя <customErrors>.

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

Возможно ли сделать обычную обработку ошибок в Application_Error, но все же разрешить ее переопределить на <customErrors>? Это даже лучшая практика или я делаю что-то в корне неправильно?

PS: Многие из наших приложений размещены на серверах наших клиентов (а не на наших собственных), поэтому «помещать всю информацию в журнал приложений и ничего не показывать пользователю» на самом деле не вариант.

Решение : заменить httpApp.Server.ClearError() на 

If Not HttpContext.Current.IsCustomErrorEnabled Then httpApp.Server.ClearError()

1 Ответ

2 голосов
/ 29 сентября 2010

Лично я большую часть времени вижу, что люди выбирают подход, подобный тому, что вы делаете. Есть несколько преимуществ, чтобы делать вещи по-своему.

  1. Ошибки больше не записываются в журнал приложений в окнах, это помогает свести к минимуму беспорядок / накладные расходы.
  2. У вас есть простой в развертывании метод добавления журнала, как вы уже упоминали.

Существует ряд обходных путей, которые я заметил в прошлом, но пользователи чаще всего заставляют своих собственных обработчиков знать настройку CustomErrors. Итак, в основном ваш код будет смотреть на код ответа, который он хочет отправить, а затем предпринимать действия на основе пользовательских ошибок. Это действительно лучшее из обоих миров.

...