Для веб-приложения ошибки неизбежны, поэтому мы должны принять меры предосторожности и обеспечить соответствующую обработку возможных ошибок. Фактически, хороший механизм обработки ошибок является важным критерием измерения качества веб-приложений. Только представьте, что когда пользователь случайно вводит неверный URL-адрес в браузере или когда пользователь предоставляет некоторую информацию, которая вызывает ошибку программы, если мы не обрабатываем эти ситуации, мы допускаем страницы с ошибками 404 или 500 или даже ошибки в информации стека. представлен пользователям, что, несомненно, отпугнет некоторых пользователей. Поэтому, когда мы разрабатываем веб-приложения, мы должны иметь полное представление о механизме обработки ошибок.
Давайте вернемся к ASP.NET и зададим всем два вопроса, над которыми стоит задуматься: сколько механизмов обработки ошибок предоставляет нам ASP.NET? Если одновременно используются несколько механизмов обработки ошибок, существует ли между ними определенный приоритет? Учитывая этот вопрос, давайте сначала взглянем на наш наиболее распространенный файл Web.Config:
<конфигурация>
<система.веб>
система.веб>
конфигурация>
Что касается элемента настройки
Далее давайте посмотрим на другой файл, который также очень часто используется: Global.asax. О чем вы думаете, когда упоминаете этот документ? Да, это события, связанные с двумя основными объектами веб-приложения (приложение и сеанс). Среди этих событий есть событие, связанное с ошибкой, которое относится к категории «Приложение» — «Ошибка», а соответствующий метод обработки события — «Application_Error». Как следует из названия, этот метод обработки событий будет вызываться при возникновении ошибки на уровне приложения, поэтому вы можете добавить в этот метод код для обработки ошибки, как показано ниже:
protected void Application_Error(object sender, EventArgs e) {
Исключение objErr = Server.GetLastError().GetBaseException();
Response.Write("Ошибка:" + objErr.Message);
Сервер.ClearError();
}
Здесь всем следует обратить внимание на использование Server.ClearError() в последней строке кода. Почему следует использовать эту строку кода? Что произойдет, если вы не воспользуетесь им? Вот попробую еще раз. Ну и второй механизм обработки ошибок — использование метода обработки событий Application_Error в Global.asax тоже дебютировал.
Можно сказать, что два вышеупомянутых метода обработки ошибок являются глобальными. Один из них получен из файла конфигурации приложения, а другой — это метод обработки событий файла Global.asax, который должен быть помещен в корневой каталог приложения. Противоположностью глобального является локальный, поэтому мы, естественно, задаемся вопросом: существует ли механизм обработки ошибок, применимый к локальному — определенной странице? Ответ «да», и есть два пути — использование атрибута ErrorPage и использование метода обработки события Page_Error. Для первого механизма практически в любой момент можно установить свойство ErrorPage, чтобы определить, на какую страницу будет перенаправлено при возникновении ошибки на странице, для второго механизма он очень похож на метод обработки события Application_Error, за исключением того, что; время срабатывания разное. Ниже приведены два конкретных примера: