Tratamiento de errores de ASP.NET

Question

En mis aplicaciones asp.net, normalmente he usado el controlador de evento global Application_Error para registrar el error y redirigir al usuario a una página de error fácil de usar.

Sin embargo, he leído acerca de ELMAH y si bien parece interesante, Application_Error parece ser el enfoque más simple.

He leído otras preguntas en las que las personas, incluido yo mismo, hemos sugerido de una forma u otra. Lo que me pregunto es si hay algún beneficio significativo para usar uno sobre el otro y por qué?

Answer 1

Elmah es un proyecto fantástico y lo usamos para todas nuestras aplicaciones ASP.NET. No solo registra los errores no controlados por usted, sino que también capta la página original completa que el usuario vio, la cual contiene muchos detalles para usted.

Tiene soporte de correo electrónico, fuentes RSS (tanto detalladas como digeridas) y tiene una consola atractiva.

Para 3 líneas en config y una referencia de dll, diría que es una volcada.

Answer 2

Supongo que el principal inconveniente de ELMAH es que podría ser excesivo para lo que necesita. Si está registrando y almacenando más información de la que tendría en su propia implementación, eso es una sobrecarga innecesaria en almacenamiento y procesamiento. También debes pensar cómo asegurar el acceso a la consola de ELMAH, ya que los detalles de esa excepción podrían contener detalles jugosos de tu aplicación (no es necesario que sea difícil, pero es una preocupación que no tenías antes).

Por otro lado, su propia implementación probablemente crecerá para registrar toda esa información adicional una vez que decida que algún error obstinado lo requiere, y realmente se preocupa por eliminar fracciones de segundo del tiempo que demora el página de error que se mostrará? Lo más probable es que eventualmente termines construyendo tu propia versión de ELMAH, entonces ¿por qué no usar ELMAH y ahorrarte tiempo?

Recomendaría que si desea escribir su propio registro de errores en lugar de utilizar ELMAH, al menos lo ponga en un módulo en lugar de directamente en Application_Error en global.asax. Simplemente suscríbase al evento Error de la aplicación en el método Init de su módulo, y puede reutilizar fácilmente su código de manejo de errores en otra aplicación con una línea en web.config.

También me parece útil manejar cualquier registro de excepción a través del monitoreo de estado de ASP.NET. Esto facilita el control del tipo y el nivel de registro en web.config, y también permite el registro de excepciones que se manejaron en un try ... catch sin llegar tan lejos como Application_Error. Cree una clase HandledExceptionEvent personalizada que extienda WebRequestErrorEvent, y puede crear y generar esos eventos en cualquier bloque de catch donde realmente le gustaría saber que la excepción ocurrió aunque se haya manejado.