Para una aplicación web, los errores son inevitables, por lo que debemos tomar precauciones y brindar un manejo adecuado ante posibles errores. De hecho, un buen mecanismo de manejo de errores es un criterio importante para medir la calidad de las aplicaciones web. Imagínese, cuando el usuario ingresa accidentalmente la URL incorrecta en el navegador o cuando el usuario proporciona alguna información que causa un error en el programa, si no manejamos estas situaciones, permitiremos páginas de error 404 o 500 o incluso errores en la información de la pila. se presenta frente a los usuarios, lo que sin duda asustará a algunos usuarios. Por lo tanto, cuando desarrollamos aplicaciones web, debemos tener una comprensión completa del mecanismo de manejo de errores.
Volvamos a ASP.NET y hagamos dos preguntas para que todos piensen: ¿Cuántos mecanismos de manejo de errores nos proporciona ASP.NET? Si se utilizan varios mecanismos de manejo de errores al mismo tiempo, ¿existe cierta prioridad entre ellos? Con esta pregunta en mente, primero echemos un vistazo a nuestro archivo Web.Config más común:
<?xml version="1.0"?>
<configuración>
<sistema.web>
<customErrors mode="Activado" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirigir="Error403.htm" />
<error statusCode="404" redirigir="Error404.htm" />
</customErrors>
</sistema.web>
</configuración>
Con respecto al elemento de configuración <customErrors>, creo que no es necesario decir más. Para obtener más información, consulte MSDN. El primer mecanismo de manejo de errores: usar el elemento de configuración <customErrors> de Web.Config debería ser el más utilizado.
A continuación, veamos otro archivo que también se usa con mucha frecuencia: Global.asax. Cuando mencionas este documento, ¿en qué piensas? Sí, son eventos relacionados con los dos objetos principales de la aplicación web (Aplicación y Sesión). Entre estos eventos, hay un evento relacionado con errores que pertenece a la categoría Aplicación: Error, y el método de procesamiento de eventos correspondiente es Application_Error. Como sugiere el nombre, este método de manejo de eventos se llamará cuando ocurra un error a nivel de aplicación, por lo que puede agregar código en este método para manejar el error, como se muestra a continuación:
protected void Application_Error(object sender, EventArgs e) {
Excepción objErr = Server.GetLastError().GetBaseException();
Response.Write("Error:" + objErr.Message);
Servidor.ClearError();
}
Aquí, todos deben prestar atención al uso de Server.ClearError() en la última línea de código. ¿Por qué debería usarse esta línea de código? ¿Qué pasa si no lo usas? Aquí lo intentaré de nuevo. Bueno, el segundo mecanismo de manejo de errores, el uso del método de manejo de eventos Application_Error en Global.asax, también hizo su debut.
Se puede decir que los dos métodos de manejo de errores anteriores son globales. Uno se deriva del archivo de configuración de la aplicación y el otro es el método de manejo de eventos del archivo Global.asax que debe colocarse en el directorio raíz de la aplicación. Lo opuesto a lo global es lo local, por lo que naturalmente nos preguntamos: ¿Existe un mecanismo de manejo de errores que se aplique a lo local, a una determinada página? La respuesta es "sí" y hay dos formas: utilizar el atributo ErrorPage y utilizar el método de manejo de eventos Page_Error. Para el primer mecanismo, puede configurar la propiedad ErrorPage casi en cualquier momento para determinar a qué página se redirigirá cuando ocurra un error en la página. Para el segundo mecanismo, es muy similar al método de manejo de eventos Application_Error, excepto que Pero; el momento en que se activa es diferente. Los siguientes son dos ejemplos específicos:
<script language="C#" runat="server">
Page_Load vacío protegido (remitente del objeto, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</script>
Page_Error vacío protegido (remitente del objeto, EventArgs e) {
Excepción objErr = Server.GetLastError().GetBaseException();
Response.Write("Error:" + objErr.Message);
Server.ClearError(); //También preste atención al uso de este código
}
En este punto, han aparecido los cuatro mecanismos de manejo de errores y es hora de clasificarlos. Ordene de prioridad alta a baja: método de manejo de eventos Page_Error > propiedad ErrorPage > método de manejo de eventos Application_Error > elemento de configuración <customErrors>. Aunque la clasificación es así, existe una relación sutil entre las clasificaciones. En primer lugar, para que el atributo ErrorPage funcione, el atributo de modo en el elemento de configuración <customErrors> debe estar configurado en "Activado"; en segundo lugar, aunque el método de procesamiento de eventos Page_Error ocupa el primer lugar, si el método Server.ClearError() lo está; desaparecido Si es así, se seguirá activando el manejo de errores de menor prioridad. Esto también se aplica al método de manejo de eventos Application_Error. El orden está ordenado, pero el orden no es el tema más importante. Incluso se puede decir que es un tema que no tiene mucho significado, porque en muchos casos es posible que no se mezclen estos cuatro mecanismos de procesamiento. Creo que la cuestión más importante es cómo elegir estos mecanismos de manejo de errores. Con respecto a este tema, espero que amigos experimentados puedan compartir sus opiniones.
Bien, eso es todo para presentar los cuatro mecanismos de manejo de errores de ASP.NET, y es hora de hablar sobre algunos de mis propios sentimientos. De hecho, los diseñadores de ASP.NET han realizado consideraciones exhaustivas desde la perspectiva de los desarrolladores, por lo que nos proporcionan hasta cuatro mecanismos de manejo de errores para que elijamos, lo cual es digno de elogio. Pero parafraseando un eslogan publicitario: demasiado es confuso, también nos marearemos un poco con tantos mecanismos de gestión de errores. Comparando el manejo de errores en el campo J2EE, podemos encontrar que es relativamente simple. La primera es la configuración correspondiente a <customErrors>. También podemos encontrar elementos de configuración similares del archivo web.xml más utilizado en proyectos J2EE: <errorPage>; en segundo lugar, en el campo de J2EE, la página no es una entidad importante y. event El modelo de controlador no es necesario, por lo que realmente no puedo encontrar el mecanismo de procesamiento correspondiente para los métodos Application_Error y Page_Error. Finalmente, en el campo de J2EE, se pone más énfasis en Solicitud y Respuesta una vez que ocurre un error en el procesamiento lógico. Podemos distribuir fácilmente la Solicitud al módulo de manejo de errores correspondiente a través de RequestDispatcher. De hecho, este es un método de procesamiento muy flexible. Los amigos que estén interesados pueden querer conocerlo.