Buenas prácticas en control de errores en ASP.NET 4.5 (WebForms)

[Carlos Admirador]

Buenas grupo !!!
Solicitando humildemente su ayuda, sus experiencias avanzadas en aplicaciones web (en mi caso asp.net 4.5 con WebForms), en concreto, el control de errores (error handling) y llegar a unas buenas prácticas

Mi idea por ejemplo es tener una página personalizada de errores,  ErrorGenerico.aspx, y a ser posible, saber en qué página se ha producido el error y mostrarlo en la página ErrorGenerico.aspx

He visto que hay dos secciones en web.config: customErrors  y httpErrors

<customErrors mode="Off" defaultRedirect="~/Informacion/ErrorGenerico.aspx" redirectMode="ResponseRedirect">
    <error statusCode="500" redirect="~/Informacion/ErrorGenerico.aspx"/>
    <error statusCode="404" redirect="~/Informacion/Error404.aspx"/>
</customErrors>

<httpErrors existingResponse="Replace" errorMode="Custom">
  <remove statusCode="404" subStatusCode="-1"/>
  <error statusCode="404" subStatusCode="-1" path="/Informacion/ErrorGenerico.aspx?error=404" responseMode="ExecuteURL"/>
  <remove statusCode="500" subStatusCode="-1"/>
  <error statusCode="500" subStatusCode="-1" path="/Informacion/ErrorGenerico.aspx?error=500" responseMode="ExecuteURL"/>
</httpErrors>

También he visto un evento enel Global.asax,   Application_Error, de momento lo tengo vacío.


        protected void Application_Error(object sender, EventArgs e)
        {

        }

Gracias de antemano grupo!!!
Saludos.
Carlos.

[Leonardo Micheloni]

Hola,

 En principio yo diferenciaría los errores 500 (del servidor, excepciones no controladas por ejemplo) de los 404, 402 que serían los producidos por el cliente (página no encontrada, acceso denegado)

 Es decir, tendría una para 404, otra para 402 y ErrorGenerico para las del tipo 500, con respecto al mensaje yo trataría de no dar tanta información sobre los errores, diría algo tipo "paso algo malo" y en todo caso guardaría registro de lo que pasó con elmah o algo así

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Carlos Admirador]

Sí, coincido no mostrar informaciónd etallada del error, eso sí trazarla. Pero si considero importante que en la página de error (500.aspx) el cliente sepa cuál es la página que generó el error.

Veo que se suele utilizar Application_Error del global.asax, no sé cuál será la buena práctica sobre ello, sobre todo evitar que se notifiquen errores.

 void Application_Error(object sender, EventArgs e) 
     {

       GlobalAsax.Application_Error(sender, e);
     }

         public static void Application_Error(object sender, EventArgs e)
     {
         if (Config.IsDev)
         {
             return;
         }
 
         Exception ex = HttpContext.Current.Server.GetLastError();
          if (ex != null)
         { 
             ex = HttpContext.Current.Server.GetLastError().GetBaseException();
         }
         Log.Write(null, ex, "Application_Error");
         HttpContext.Current.Response.Redirect("~/Web/Page/Common/ErrorPage.aspx");
     }


Otro ejemplo:

           protected void Application_Error(object sender, EventArgs e)
         {

             var ex = Server.GetLastError().GetBaseException();
 
             //Do not log 404 exceptions
             if (ex is HttpException)
             {
                 if (ex.Message.Contains("The controller for path"))
                 {
                     return;
                 }
             }
             var message = String.Format("[{0}@{1}] {2}\n{3}",
                 "Application_Error",
                 "Global.asax.cs",
                 ex.Message,
                 ex.StackTrace
                 );
 
             log.Fatal(message);

[Carlos Admirador]

Hola gente!!! Desde IMHO totalmente ignorante, Asp-net-health-monitoring es poco conocido o menos utilizado, no he visto aún buenas prácticas al respecto con Asp-net-health-monitoring,Failed Request Tracing, httpErrors, customErrors, Global.asax Application_Error, BasePage OnError con Ent.Library Logging y Exception Handling...

Asp-net-health-monitoring
mvolo.com/asp-net-health-monitoring-8-years-later/

Failed Request Tracing
www.iis.net/.../troubleshooting-failed-requests-using-tracing-in-iis

httpErrors
www.iis.net/.../how-to-use-http-detailed-errors-in-iis

customErrors

EMLAH o Enterprise Logging and Exception

Global.asax Application_Error

BasePage OnError

Alguna experiencia al respecto pueden compartir?

Saludos!

[Miguel Eduardo Román Martínez]

Una solución que me ha funcionado muy bien a mi (no se si se adapte a tu escenario) es el uso de Exceptionless.

http://exceptionless.com/

https://github.com/exceptionless/Exceptionless

En una fase inicial para realizar tus pruebas y ver si cumple con tus expectativas, puedes registrarte gratuitamente para un proyecto en la página oficial. Y si las opciones de pago no se adaptan a tus necesidades, puedes tener una instancia de exceptionless en tus propios servidores porque es OpenSource.

Es bastante fácil de implementar en tu proyecto, solo es de agregar el Nuget Package y empezará a registrar las excepciones no controladas en tu proyecto (registra aparte de los detalles de la excepción, la página en donde ocurrió, datos que iban en el post, datos del servidor, el usuario logueado en la aplicación, etc.) tambien lo puedes configurar para guardar logs de la aplicación.

Aparte de esto puedes implementar una pagina personalizada que le indique al usuario que ocurrió un error pero que no le de detalles del error.

A mi me ha ido de maravilla con Exceptionless lo tengo instalado de forma local y notifica por correo cuando hay excepciones nuevas, las puedes marcar como corregidas y te notifica por correo si vuelve.

Como una segunda fase ya lo puedes integrar directamente en tu código si necesitas enviar mayor información que pueda ser útil para resolver el problema, por ejemplo:

try {

   /* Hacer algo */

} catch(Exception ex) {

  ex.ToExceptionless().AddObject(new { orden: ordenDeCompra, id: transaccionId }).Submit();

  throw new ApplicationException("Error al crear la orden de compra");

}

Espero te sea de utilidad la información.

Saludos,

Miguel Román

[Carlos Admirador]

¡Gracias Miguel!

Lo investigaré un poco, a ver si encuentro aplicación que haga uso de Exceptionless y sirva de base para minimizar curva de aprendizaje
https://github.com/search?l=csharp&p=6&q=ToExceptionless+&ref=searchresults&type=Code&utf8=%E2%9C%93

La notificación por correo lo configuras en el web.config o a través de la web de administración de exceptionless.com ?

De la página personalizada, puedes dar más detalles? Configuras a través de customErrors ?

Gracias de antemano.

Saludos
Carlos.

[Miguel Eduardo Román Martínez]

Que tal Carlos, te comparto este pequeño proyecto https://github.com/miguelerm/DemoExceptionless

En el Web.Config está configurada la apiKey que te brinda la página de Exceptionless cuando te registras.

En el Global.asax se configuran dos cosas:

• El Application_Error que hará un redirect a las paginas personalizadas de error.
• Un event handler para el evento SubmittingEvent de Exceptionless que agrega en el HttpContext el id de la excepción para poder mostrarlo en la página personalizada y poder buscarlo después en exceptionless (tambien ignora los errores 404 para no enviarlos a Exceptionless, aquí puedes ir filtrando los errores que no quieras enviar).

En el Default.aspx solo hay dos botones que generan excepciones, una excepción capturada con try catch, y otra excepción que no está capturada por ningún try catch.

Con respecto a lo del envío de correo eso lo hace la plataforma de exceptionless, ya que cuando te registras lo haces con una cuenta de correo, a esa cuenta te enviará los correos de las excepciones. Ahora bien, si vas a instalar Exceptionless de forma local, en el Web.Config de esa instalación de exceptionless tienes que configurar el smtp para envío de correos. tu aplicación queda "casi" igual, solo hay que especificar en el web.config la url a la que debe enviar las excepciones porque ya no será a https://exceptionless.com sino que será tal vez a http://tuservidor.com

Espero te sea de utilidad el ejemplo, si no cualquier duda con gusto.

Saludos,

Miguel

[Carlos Admirador]

Muchas gracias Miguel por compartir el ejemplo y tus aclaraciones. FAntástico!

Instalar Exceptionless de forma local es instalarlo(desplegarlo) en otro sitio web entiendo.
Lo importante en el Global.asax con el  Application_Error (Server.Transfer a páginas personalizadas) y el
SubmittingEvent de Exceptionless. No necesario nada de customErrors ni httpErrors.

En el web.config también aparece un module específico: Exceptionless.Web.ExceptionlessModule, Exceptionless.Web

Saludos gente!
Carlos

[Carlos Admirador]

Hola gente!

De Asp-net-health-monitoring, lo que se comenta en mvolo.com/asp-net-health-monitoring-8-years-later/, "rarely find people advocating the use of Health Monitoring", no se  conoce o no se utilza,
En la misma referencia se habla de s us desventajas y ventajas: "read 18 pages of MSDN documentation for every aspect of HM",

De Failed Request Tracing http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis  no me queda claro si tiene impacto sobre el rendimiento en IIS 7.5 en un entorno de producción si se habilita

http://stackoverflow.com/questions/24416447/iis-failed-request-tracing-performance-view-doesnt-show-time-spent
http://blogs.msdn.com/b/tess/archive/2008/08/19/troubleshooting-a-performance-issue-with-failed-request-tracing-and-appcmd-in-iis7.aspx
http://serverfault.com/questions/231216/keep-iis7-failed-request-tracing-as-a-sysadmin-only-diagnostic-tool

http://blogs.msdn.com/b/benjaminperkins/archive/2012/01/02/enable-and-activate-failed-request-tracing-rules.aspx

"Just don’t forget to turn off or manage the log files you are creating, they can have impact on performance if they grow unmanaged."

"the writting of IIS logs is not real time, the logs are stored in memory and at some point the IIS logs are written.  The process is different than the one responding to web requests.  So I would not expect the logging to have significant direct negative impact on the responding of a request.  BUT, do manage the size of the files.  The resource required to write logs to a 1MB file would be less than writting to a 10GB file, so manage your IIS logs appropriately. "

alguien de la comunidad quiere aportar sus experiencias con HM y FRT si las tiene?.

Saludos gente !
Carlos

[Carlos Admirador]

A tener en cuenta, 

Modo de redirección de errores personalizados en ASP.NET y su impacto en SEO e imagen

https://www.jasoft.org/Blog/post/PermaLinkaspxguid=ba188f82-b770-49e3-a7a0-559173b.aspx