Cuando estamos construyendo una aplicación con ASP.NET MVC y estamos haciéndolo utilizando AJAX debemos tomar una especial precaución al momento de ver los errores que pueda devolver nuestro programa.
Cuando una solicitud falla obtendremos un error 500 de servidor lo que no es algo bueno que deba ver el usuario o tal vez obtengamos un mensaje con la traza del error de ASP.NET que si no lo capturamos antes puede verse fuera y un usuario mal intencionado pudiera obtener datos para utilizarlos y atacar nuestro sitio.
Para evitar mayores problemas cuando nuestra aplicación devuelve un error debemos trabajar en manejar estos como excepciones, de forma que antes que dé el error nuestra aplicación pueda saber esto y arrojar un mensaje más amigable al usuario y que no comprometa nuestra seguridad.
Una excepción ocurre cuando una porción de nuestro código intenta realizar una acción y falla, ya sea que intenta consultar datos inexistentes o porque no validamos alguna entrada de datos del usuario, si estamos utilizando AJAX puede que obtengamos un error 500, pero también si no pasa esto y llega un dato erróneo a nuestro controlador pudiéramos obtener una traza de error como la que vemos en la siguiente imagen:
Las trazas de error pocas veces ofrecen una cantidad de información útil para el desarrollador y si no limpiamos lo que va a mostrar podemos comprometer la seguridad del sitio al filtrar datos de configuración de nuestra aplicación o de nuestro servidor.
Para evitar todos los problemas que se pueden generar al ocurrir un error en ASP.NET podemos manejar dichos errores como excepciones y para ello podemos capturar el error y enviar un mensaje personalizado o simplemente enviar una respuesta que la página que se busca no existe.
En la siguiente imagen vemos un código que utiliza el método mencionado para manejar la excepción, veamos:
![asp_manejo_excep2.jpg]()
Aquí lo que ocurre es bastante simple, primero hacemos la búsqueda del elemento por el id, en caso que nos retorne vacío o inexistente, para nuestro ejemplo lo validamos con null, vamos a establecer un mensaje de error, con el método HttpResponseException establecemos un código de no encontrado y preparamos un mensaje personalizado, finalmente lanzamos ese mensaje.
Gracias a esto evitamos enviar una respuesta nula o vacía a nuestra aplicación lo que podría haber hecho que se rompiera en algún punto y mostrara un error de forma incorrecta, también le enviamos un mensaje más amigable al usuario indicando el por qué su consulta no arroja resultados.
Al obtener un mensaje personalizado también podemos dar una información más específica que pueda utilizar un desarrollador, es más sencillo saber que el producto no existe, a tener que revisar una traza de 100 líneas para averiguar lo mismo.
Finalizamos el tutorial habiendo aprendido un poco más sobre los riesgos de no manejar los errores, además de haber aprendido como manejar los mismos al tratarlos como excepciones.
Cuando una solicitud falla obtendremos un error 500 de servidor lo que no es algo bueno que deba ver el usuario o tal vez obtengamos un mensaje con la traza del error de ASP.NET que si no lo capturamos antes puede verse fuera y un usuario mal intencionado pudiera obtener datos para utilizarlos y atacar nuestro sitio.
Para evitar mayores problemas cuando nuestra aplicación devuelve un error debemos trabajar en manejar estos como excepciones, de forma que antes que dé el error nuestra aplicación pueda saber esto y arrojar un mensaje más amigable al usuario y que no comprometa nuestra seguridad.
Excepción
Una excepción ocurre cuando una porción de nuestro código intenta realizar una acción y falla, ya sea que intenta consultar datos inexistentes o porque no validamos alguna entrada de datos del usuario, si estamos utilizando AJAX puede que obtengamos un error 500, pero también si no pasa esto y llega un dato erróneo a nuestro controlador pudiéramos obtener una traza de error como la que vemos en la siguiente imagen:
Las trazas de error pocas veces ofrecen una cantidad de información útil para el desarrollador y si no limpiamos lo que va a mostrar podemos comprometer la seguridad del sitio al filtrar datos de configuración de nuestra aplicación o de nuestro servidor.
Controlar lo que se Muestra
Para evitar todos los problemas que se pueden generar al ocurrir un error en ASP.NET podemos manejar dichos errores como excepciones y para ello podemos capturar el error y enviar un mensaje personalizado o simplemente enviar una respuesta que la página que se busca no existe.
¿Qué utilizar?
Para realizar esto podemos utilizar el método HttpResponseException que nos permite pasar como parámetro un código HTTP como el 404 de página no encontrada.
En la siguiente imagen vemos un código que utiliza el método mencionado para manejar la excepción, veamos:
Aquí lo que ocurre es bastante simple, primero hacemos la búsqueda del elemento por el id, en caso que nos retorne vacío o inexistente, para nuestro ejemplo lo validamos con null, vamos a establecer un mensaje de error, con el método HttpResponseException establecemos un código de no encontrado y preparamos un mensaje personalizado, finalmente lanzamos ese mensaje.
Gracias a esto evitamos enviar una respuesta nula o vacía a nuestra aplicación lo que podría haber hecho que se rompiera en algún punto y mostrara un error de forma incorrecta, también le enviamos un mensaje más amigable al usuario indicando el por qué su consulta no arroja resultados.
Al obtener un mensaje personalizado también podemos dar una información más específica que pueda utilizar un desarrollador, es más sencillo saber que el producto no existe, a tener que revisar una traza de 100 líneas para averiguar lo mismo.
Finalizamos el tutorial habiendo aprendido un poco más sobre los riesgos de no manejar los errores, además de haber aprendido como manejar los mismos al tratarlos como excepciones.
