Manejando Errores (404 etc.)

Manejar excepciones es muy importante en todos los tipos de aplicaciones, pero como se ha discutido en el artículo previo, también necesitas estar al tanto de otros tipos de errores cuando desarrollas una aplicación para la web. El servidor (p.ej. IIS en Windows o Apache en Linux/Unix) y el cliente (usualmente un navegador p.ej. Chrome) se comunican usando el protocolo llamado HTTP, el que requiere que el Server siempre incluya un código de estado cuando responde a un requerimiento. Si todo va como se esperaba, el código de respuesta normalmente sería 2xx p.ej. 200, que simplemente significa "OK" (en este caso abreviación de "Todo salió bien - aquí está el resultado").

Por otro lado, si las cosas no salen como se esperaba, otro tipo de código de estado será devuelto. Uno de los más conocidos es el 404, que es devuelto cuando el Server no puede encontrar el recurso solicitado por el usuario. Este es también el mejor ejemplo de un código de estado que debería ser manejado por ti. Por que?, porque si no lo haces, estarás confiando en la página de error por defecto, ya sea del servidor web (si tiene una) o incluso la del navegador. Esto no se ve muy bien, ya que se vuelve muy obvio que esta página no es realmente una parte de tu sitio web, pero talvez aún peor, evita que tu aplicación se de cuenta que falta una página.

Manejando errores (p.ej. 404) elegantemente

Lo que necesitamos hacer en su lugar es capturar este tipo de errores, registrarlos y mostrar un mensaje amistoso al usuario. Como tenemos el control total de estos mensajes, este puede incluir cualquier cosa, desde una corta disculpa y una foto divertida hasta un e-mail donde el usuario puede decirte más sobre como terminó en esta página, lo que puede ayudarte a arreglarlo.

El método UseStatusCodePages()

Por defecto, cuando un código de estado no exitoso debería ser retornado, "ASP.NET Core" no hace nada mas que retornar el código de estado actual junto con una página de respuesta vacía - en otras palabras, el cliente (browser) tendrá que verlo desde aquí y dejar saber al usuario que algo salió mal. Esto es muy fácil de cambiar - simplemente debes incluir una llamada a app.UseStatusCodePages() en el método Configure() del archivo Startup.cs, como a continuación:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseStatusCodePages();
    ....

Siempre que trates de acceder a una página no existente, desde ahora tendrás una respuesta como ésta:

Status Code: 404; Not Found

Eso no es, realmente, mas amistoso que dejar que el navegador lo maneje, pero prueba que esos errores ahora son manejados por tu aplicación en vez del navegador. Una versión un poco mas amistosa podría lucir como esto:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseStatusCodePages("text/html", "We're <b>really</b> sorry, but something went wrong. Error code: {0}");
    ....

La sobrecarga de UseStatusCodePages() te hace fácil el personalizar el mensaje de error, pero aún no luce como el resto de la aplicación y aún no podemos registrar el problema. Pero no te preocupes - existen varios métodos relacionados que puedes usar. Para resolver el problema de poder registrar el error, podemos usar otra sobrecarga de UseStatusCodePages() que nos da aún mas control:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseStatusCodePages(async context =>
    {
    context.HttpContext.Response.ContentType = "text/html";

    if(context.HttpContext.Response.StatusCode == 404)
    {
        // Log this error here, e.g. to a database. You can use the context.HttpContext.Request 
        // object to access important information like the requested URL
    }

    await context.HttpContext.Response.WriteAsync(
        "We're <b>really</b> sorry, but something went wrong. Error code: " +
        context.HttpContext.Response.StatusCode);
    });
    ....

Con ésta sobrecarga, finalmente tomamos el control que necesitamos: Podemos registrar el error y podemos entonces generar una respuesta buena para el usuario, con todo el código HTML que queramos. Sin embargo, generar una página de error completa en HTML, con C# no es lo ideal, así que si quieres una página de error mas sofisticada, te sugiero usar otro enfoque.

El método UseStatusCodePagesWithRedirects()

Reemplazaremos el método UseStatusCodePages() con una llamada a UseStatusCodePagesWithRedirects(). Como el nombre lo indica, responderá con una redirección en vez del mensaje actual. Podremos entonces redireccionar hacia cualquier acción en nuestra aplicación, lo que a la vez significa que podemos responder con una vista - incluso una vista que use un diseño, que finalmente nos permitirá conseguir una página de error que se vea como el resto del sitio web.

En el artículo anterior, hablamos sobre excepciones y como tendría sentido el implementar un ErrorController para manejar excepciones inesperadas. Esto también tiene sentido cuando se lidia con códigos de estado HTTP, como el del error 404. podrías entonces implementar una acción en este controlador que lidie con este tipo de errores. Pero primero, cambiemos el método Configure del archivo Startup.cs para usar este enfoque:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseStatusCodePagesWithRedirects("/Error/Http?statusCode={0}");
    ....

Hecho esto, todos los errores HTTP serán redireccionados a un método llamado "Http" en el ErrorController y el código de estado actual será incluido como parámetro. El método Http() podría lucir como el siguiente:

public class ErrorController : Controller  
{  

    public IActionResult Http(int statusCode)  
    {  
    if(statusCode == 404)  
    {  
        // Log this error here, e.g. to a database. You can use the HttpContext.Request   
        // object to access important information like the requested URL  
    }  
    // Return a View where the problem is explained. It can use the common Layout or not  
    // and you can even make specific views for the types of errors you want to handle,  
    // e.g. Error404.cshtml, as shown here...  
    if(statusCode == 404)  
        return View("Error404");  
    return View();  
    }  
    ....

Ahora tenemos todo lo que nos propusimos lograr: Una página de error amistosa que se puede mimetizar con el resto del sitio web (porque puede usar un diseño existente de la aplicación) y la habilidad de registrar el error.

Sumario

Manejar errores HTTP en la aplicación es un buen detalle, porque nos permite mostrar mensajes de error amistosos, pero es también importante porque nos permite registrar los problemas. En combinación con el manejo de excepciones, que fue descrito en el artículo anterior, nos ayudará a crear aplicaciones web mucho más robustas .