Для веб-приложения ошибки неизбежны, поэтому мы должны принять меры предосторожности и обеспечить соответствующую обработку возможных ошибок. Фактически, хороший механизм обработки ошибок является важным критерием измерения качества веб-приложений. Только представьте, что когда пользователь случайно вводит неверный URL-адрес в браузере или когда пользователь предоставляет некоторую информацию, которая вызывает ошибку программы, если мы не обрабатываем эти ситуации, мы допускаем страницы с ошибками 404 или 500 или даже ошибки в информации стека. представлен пользователям, что, несомненно, отпугнет некоторых пользователей. Поэтому, когда мы разрабатываем веб-приложения, мы должны иметь полное представление о механизме обработки ошибок.
Давайте вернемся к ASP.NET и зададим всем два вопроса, над которыми стоит задуматься: сколько механизмов обработки ошибок предоставляет нам ASP.NET? Если одновременно используются несколько механизмов обработки ошибок, существует ли между ними определенный приоритет? Учитывая этот вопрос, давайте сначала взглянем на наш наиболее распространенный файл Web.Config:
<?xml version="1.0"?>
<конфигурация>
<система.веб>
<customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="Error403.htm" />
<error statusCode="404" redirect="Error404.htm" />
</customErrors>
</система.веб>
</конфигурация>
Что касается элемента настройки <customErrors>, думаю, нет необходимости говорить больше. Подробности можно найти в MSDN. Первый механизм обработки ошибок — использование элемента конфигурации <customErrors> 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, за исключением того, что; время срабатывания разное. Ниже приведены два конкретных примера:
<script Language="C#" runat="server">
protected void Page_Load (отправитель объекта, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</скрипт>
protected void Page_Error (отправитель объекта, EventArgs e) {
Исключение objErr = Server.GetLastError().GetBaseException();
Response.Write("Ошибка:" + objErr.Message);
Server.ClearError(); //Также обратите внимание на использование этого кода
}
К этому моменту все четыре механизма обработки ошибок появились, и пришло время их ранжировать. Сортировка от высокого приоритета к низкому: метод обработки событий Page_Error > свойство ErrorPage > метод обработки событий Application_Error > элемент конфигурации <customErrors>. Несмотря на то, что рейтинг такой, между рейтингами существует тонкая взаимосвязь. Во-первых, чтобы атрибут ErrorPage работал, атрибут mode в элементе конфигурации <customErrors> должен быть установлен в значение «On», во-вторых, хотя метод обработки события Page_Error занимает первое место, если есть метод Server.ClearError(); отсутствует. В этом случае обработка ошибок с более низким приоритетом все равно будет запущена. Это также верно для метода обработки событий Application_Error. Порядок установлен, но порядок не является самым важным вопросом. Можно даже сказать, что это вопрос, который не имеет большого значения, потому что во многих случаях вы не можете смешивать эти четыре механизма обработки. Я думаю, что наиболее важным вопросом является выбор механизмов обработки ошибок. По этому вопросу, надеюсь, опытные друзья поделятся своим мнением.
Ладно, на этом мы познакомились с четырьмя механизмами обработки ошибок ASP.NET, и пришло время поговорить о некоторых моих ощущениях. Разработчики ASP.NET действительно тщательно рассмотрели точку зрения разработчиков, поэтому они предоставляют нам на выбор целых четыре механизма обработки ошибок, что заслуживает похвалы. Но перефразируя рекламный слоган — слишком многое сбивает с толку, от такого количества механизмов обработки ошибок у нас тоже немного закружится голова. Сравнивая обработку ошибок в области J2EE, мы видим, что она относительно проста. Во-первых, это параметр, соответствующий <customErrors>. Мы также можем найти аналогичные элементы конфигурации в наиболее часто используемом файле web.xml в проектах J2EE: <errorPage>, во-вторых, в области J2EE страница не является важной сущностью и; Event Модель драйвера не обязательна, поэтому я действительно не могу найти соответствующий механизм обработки для методов Application_Error и Page_Error. Наконец, в области J2EE больше внимания уделяется запросу и ответу. Как только возникает ошибка в логической обработке; Мы можем легко передать запрос соответствующему модулю обработки ошибок через RequestDispatcher. На самом деле, это очень гибкий метод обработки. Друзья, которые заинтересованы, возможно, захотят узнать об этом.