¿Cuáles son las pautas definitivas para el manejo personalizado de errores en ASP.NET MVC 3?

44

El proceso de hacer el manejo de errores personalizado en ASP.NET MVC (3 en este caso) parece ser increíblemente descuidado. He leído varias preguntas y respuestas aquí, en la web, páginas de ayuda para varias herramientas (como Elmah), pero siento que he completado un círculo completo y aún no tengo la mejor solución. Con su ayuda, quizás podamos establecer un nuevo enfoque estándar para el manejo de errores. Me gustaría mantener las cosas simples y no aplicar demasiada ingeniería a esto.

Aquí están mis metas:

Para errores / excepciones del servidor:

  1. Mostrar información de depuración en dev
  2. Mostrar la página de error amigable en producción
  3. Registre los errores y envíelos por correo electrónico al administrador en producción
  4. Devolver 500 código de estado HTTP

Para errores 404 No encontrados:

  1. Mostrar página de error amigable
  2. Registre los errores y envíelos por correo electrónico al administrador en producción
  3. Devolver código de estado HTTP 404

¿Hay alguna manera de cumplir estos objetivos con ASP.NET MVC?

    
pregunta RyanW 21.01.2011 - 21:07

2 respuestas

23

Compartiré la forma en que terminé haciendo esto, eso fue parte de la pregunta original.

Primero, los problemas que encontré:

  1. Con customErrors en (es decir, en producción), el atributo global HandleError traga las excepciones y presenta la vista de error, pero luego no puede registrarlo con una herramienta adicional como elmah, ya que elmah nunca lo ve. Podría registrarlo en su vista, supongo, pero es una vista que parece incorrecta. El atributo global de HandleError aparece como nuevo en la plantilla de proyecto de MVC 3 RTM Visual Studio.

  2. customErrors con urls para puntos finales de MVC devuelve 302 códigos de estado. Existe la propiedad redirectmode, pero no puede hacer coincidir las direcciones URL de mvc en customErrors y utilizar el modo ResponseRewrite. ( enlace )

  3. Evitar CustomErrors completamente y manejar todo lo personalizado en su aplicación lleva a una gran complejidad, IMO. (Me encantó esto: enlace , pero no fue correcto para nuestro proyecto)

Mi solución

He eliminado a MVC de la ecuación por completo. He eliminado el filtro global HandleErrorAttribute en global.asax y me he centrado completamente en la configuración de customErrors, cambiándolo para usar las redirecciones de WebForm y cambie al modo redirigido a ResponseRewrite para evitar los 302 códigos de respuesta HTTP.

<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
  <error statusCode="404" redirect="/NotFound.aspx" />
</customErrors>

Luego, en el evento NotFound.aspx page_load, establece Response.StatusCode en 404 y en Error.aspx establece el código 500.

Resultados:

Los objetivos para ambos se han logrado con los registros de Elmah, la página de error amigable y el código de estado con una línea de código en los códigos subyacentes. No lo haremos a la "manera MVC" como lo hace la solución anterior, pero estoy de acuerdo con eso si son dos líneas de código.

    
respondido por el RyanW 07.02.2011 - 22:04
5

Creo que MVC, ASP y su marco de manejo de excepciones / registro favorito pueden manejar sus objetivos bastante bien. ELMAH y Enterprise Library proporcionan un manejo y un registro de excepciones fáciles de usar, así que elige tu favorito. No voy a entrar en los pros y los contras de cada uno aquí.

NOTA: no puede mostrar una página de error amigable Y devolver un HTTP 404 o 500 como sugiere su pregunta. Cuando devuelva una página de error amigable, el código HTTP devuelto a su navegador será 302. Esta es una redirección a la página de error amigable.

Páginas de error amigables

Parece que puedes lograr tus objetivos con la buena configuración de web.config que ha sido parte de ASP.net durante algún tiempo. Usted menciona que muestra información de depuración cuando está en desarrollo y que muestra páginas amigables en producción. Puede usar la sección de errores personalizados de web.config para esto (establezca CustomErrors="Off" para mostrar información de depuración). Asumiré que está familiarizado con el atributo CustomErrors, si no lee esto:

enlace

Si necesita una mayor granularidad de control sobre las vistas de error que muestra, use el atributo HandleError de MVC. De esta manera, puede elegir diferentes vistas de error para cada Acción / Controlador.

enlace

Registro de excepciones

Parece que desea responder a todas sus excepciones de la misma manera ('Registrar errores y enviarlos por correo electrónico al administrador en producción'). Si este es el caso, su opción más simple es agregar código a

Application_Error (objeto remitente, EventArgs e)

en su global.asax. Aquí es donde puede pasar al marco de registro elegido.

Si desea tener más control sobre su registro / manejo de excepciones, puede subclase HandleErrorAttribute y anular

OnException(System.Web.Mvc.ExceptionContext filterContext)

este es otro lugar donde puede pasar al marco de registro elegido.

enlace

Esto le da más control que la técnica Application_Error mencionada anteriormente.

En general, MVC le brinda una gran granularidad de control sobre cómo manejar los errores. Si no necesita este control, puede recurrir a las formas de ASP.net de hacer cosas como definir páginas de error en su web.config.

    
respondido por el nixon 05.02.2011 - 19:45

Lea otras preguntas en las etiquetas