Prácticas recomendadas: Excepciones en .NET

Siguiendo con la temática de un post reciente de braulio:

Desde PHP 5 podemos hacer el uso de excepciones como casi en cualquier lenguage de programación, ¿excelente verdad? Pero hay que tener en cuenta que aunque las excepciones sean una gran herramienta, también podrían ser peligrosas cuando son usadas indebidamente, por ejemplo nuestra aplicación podría consumir muchos recursos.

La misma recomendación se aplica para cualquier lenguaje en realidad, no solo PHP, por ejemplo hoy mismo salió publicado un artículo en favor de la utlización del método TryParse por sobre el método Parse.

Un ejemplo simple

Supongamos que necesitamos obtener el ID de un producto vía QueryString, convertirlo a entero para luego poder llamar al método de una clase para buscar el producto en la base de datos, en .NET 1.1 podríamos utilizar el siguiente código:

protected void Page_Load(object sender, EventArgs e)
{
try
{
int productID = int.Parse(Request.QueryString["productID"]);
// lógica para buscar el producto va aquí...
}
// el valor pasado por QueryString no es un número
catch (Exception ex)
{
throw ex;
}
}

Ahora bien, no sería extraño que alguien intente pasar el valor "productID=$%()", lo que resultaría en una excepción, por lo que el proceso de nuestra aplicación comenzaría a utilizar más y más recursos sin ningún sentido, peor aún, ni hablar si estamos logeando –algo que considero una práctica recomendada– (por ejemplo a un archivo de texto/base de datos, o enviando un mail a la persona responsable) cada vez que ocurre un error, como ven el problema empieza a escalar.

La solución

protected void Page_Load(object sender, EventArgs e)
{
int productID;
if (int.TryParse(Request.QueryString["productID"], out productID))
{
// lógica para buscar el producto
}
else
{
// el valor no es un número
}
}

El segundo ejemplo, es obviamente una solución mucho más inteligente, el método TryParse simplemente devuelve False, sin devolver una excepción.

Es importante entender que sólo deberíamos "tirar" una excepción cuando ocurre un imprevisto (en este caso aunque no es lo esperado es absolutamente posible que el valor de productID que proviene del QueryString no sea un número), algo fuera de lo normal (un error que no pudimos predecir) o algo para lo cual no existe una solución para que la aplicación siga funcionando (algo totalmente terminal, por ejemplo que falle el servidor de base de datos)

Espero sea útil.

Nota: esta entrada es un cross-post.

Instalación de Visual Studio 2005 SP1 beta

Bueno, para hacerla corta tal como lo dijo Alex la instalación fue un martirio, pero hay algo que me pareció bastante malo (por sobre todas las cosas)…

Si tenés instalado los WAP, después de que carga el MSI de instalación (que por cierto no es algo rápido, al menos 3-5 mins) te dice algo como “Para instalar SP1 es necesario desinstalar los WAP primero”, en un diálogo con solamente el botón “OK”, al presionar OK se cierra el diálogo y vuelve a iniciarse la instalación, resultando en el mismo diálogo, otra vez. Osea que hay que cerrar la instalación, desinstalar WAP y empezar de nuevo…

Pregunto, no sería más práctico algo como: “Para instalar SP1 es necesario desinstalar los WAP primero, ¿querés desinstalarlo ahora? OK (desinstalo WAP y sigo) – CANCEL (salgo de la instalación)”

Nota: esta entrada es un cross-post.

Publicando en Geeks.ms

A partir de hoy el contenido que publique en este blog también será publicado en Geeks.ms (cross-posting)

Sobre Geeks.ms

En este sitio encontrarás todo aquello que los geeks en infraestructura y desarrollo en plataforma Microsoft tienen que contar al mundo. Entre nuestros geeks se encuentran numerosos MVPs y varios MCTs!!!.

Eso sí, por una cuestión de orden les pido que los comentarios los dejen aquí (osea en la dirección original de mi blog). Así no tengo que revisar comentarios en múltiples lugares :)

Me alegra formar parte de esta comunidad y espero que lo que publique les sea útil.

Nota: esta entrada es un cross-post.