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:
Con respecto al elemento de configuración
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:
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
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