2009-04-05 17 views
11

Estoy intentando implementar el manejo global de errores en mi aplicación MVC.MVC Global error handling: Application_Error no dispara

Tengo un poco de lógica dentro de mi Application_Error que redirige a un ErrorController pero no está funcionando.

Tengo un punto de quiebre dentro de mi método Application_Error en el Global.aspx.

Cuando fuerzo una excepción, no se golpea el punto de ruptura. ¿Alguna idea de por qué?

+0

¿Ha intentado ejecutar la aplicación en modo no depuración? CTR + F5 –

+0

¿Su método tiene la firma correcta? Application_Error (objeto remitente, EventArgs e) y no Application_Error()? –

+0

está presente en su web.config? –

Respuesta

10

Puede probar este enfoque para las pruebas:

protected void Application_Error(object sender, EventArgs e) 
{ 
    var error = Server.GetLastError(); 
    Server.ClearError(); 
    Response.ContentType = "text/plain"; 
    Response.Write(error ?? (object) "unknown"); 
    Response.End(); 
} 

Web.config

<customErrors mode="Off" /> 
+0

¡No! Esa es una mala idea. Quiero el manejo de error global, registrar el error y presentar una pantalla amigable para el usuario. – Dan

+0

Tus enlaces no son realmente relevantes para mi pregunta. – Dan

+2

@ Dan, no entendiste mi punto. El depurador simplemente no puede ingresar a su método Application_Error. Usa mi código sin depurador y verás que funciona. Por cierto, derrotas a cualquier desier para que te ayude. –

0

No puedo decir con seguridad qué' está mal, pero puedo pensar en un par de cosas para verificar ... en primer lugar, ¿VS está rompiendo la excepción? Si está en el depurador, este es el valor predeterminado, creo. Si solo toca F5 hasta llegar a su código con el punto de interrupción. Además, ¿está seguro de que no maneja la excepción en ningún lado antes de que llegue al Application_Error?

Otra cosa para comprobar - CustomErrors modo en web.config, esto se establece en Off, ¿verdad?

+0

No, no lo maneje en otro lado, estoy obteniendo una página de error asp.net estándar poco agraciada. – Dan

+0

OK gracias, agregué otro pensamiento a mi publicación. –

2

Creo que una mejor manera de manejar esto sería usando el HandleErrorAttribute para decorar su controlador (quizás un controlador base). Esto le daría la opción de registrar o manejar errores en diferentes controladores con diferentes errores extendiendo este atributo y modificándolo para que se ajuste a sus necesidades, digamos cambiando la vista que se procesa. El uso de este atributo utiliza el procesamiento de filtro estándar en MVC y crea la página utilizando vistas en lugar de escribir directamente en la respuesta como lo haría con Application_Error.

+2

El uso del atributo HandleError no ayuda con los errores que ocurren fuera de los controladores hasta donde puedo decir (por ejemplo, en RegisterRoutes en Global.asax.cs). –

+2

@Michael - cierto, solo se aplica a un controlador o método de controlador ya que el marco solo reconoce los atributos allí. En la práctica, no creo que esto sea un problema. Para mí, el único código que se ejecuta fuera de una acción se realiza al inicio.Yo uso ELMAH con un atributo HandleError personalizado de todos modos, así que ambas bases están cubiertas. – tvanfosson

+0

@tvanfosson lo mismo para llamadas ajax, también. Va directo a la aplicación.error global.asax si lo tiene ... después de algunas investigaciones y pruebas, he decidido una solución de tres puntas. A. atributo personalizado utilizando RegisterGlobalFilters no decorada controladores B. Actualización de web.config para convertir el manejo de error personalizado en C. JavaScript que captura todos los mensajes, ya sea utilizando el modelo y un método de ayuda o directamente desde el código de estado ajax y un redireccionamiento a la página de error a través de javaScript mediante el cual el modelo y el ajax canalizan su error en – Clarence