Posts Tagged ‘excepciones’

Excepciones en .NET, ¿seguro que quieres manejar un System.Exception?

25 septiembre 2009

Hola, aquí Luis (presentación copiada de los blogs de los equipos de productos de MS) 🙂

Retomando un post anterior relacionado con el manejo de excepciones y la diferencia entre Throw y Throw ex, he leído algunas cosas interesantes sobre el manejo general de excepciones.

El título de uno de los post que he leído, dice algo como: “Porque un empty catch o un catch(exception) es una mala idea“, pero visto el profundo debate de comentarios que ha provocado el post, yo no me atrevería de decir tanto 🙂

El artículo en cuestión, recomienda no hacer catch del tipo System.Exception, y utilizar Excepciones hija (ArgumentException, etc). Es decir, fíjate en la operación que estás haciendo, y en las excepciones que se pueden lanzar. Ejemplo, si intentas abrir un fichero, una de las posibles excepciones será FileNotFoundException.

La razón que da el artículo, es que una excepción del tipo System.Exception, significa un fallo de sistema (recomiendo que leáis estos 2 artículos que se enlazan desde el primer post y que son del gran Krzysztof Cwalina:

y los fallos de sistema, “no tienen nada que manejar”. Vamos, que si tienes un fallo de puntero en memoria, busca el puntero y llévalo al taller!…

Pero entonces, ¿nos tenemos que olvidar del típico bloque?

try

catch ex as Exception

Pues hombre, aquellos de vosotros que estéis acostumbrados a desarrollar servicios 24×7 y a integrar varios sistemas, cada uno de su padre y de su madre, seguramente os parecerá duro renunciar a dicho bloque. Sinceramente, a mi también me lo parece. En esas ocasiones, creo que conviene manejar fallos de sistema y hacer un buen log del mismo, además de tomar la decisión de si queremos matar el servicio o seguimos funcionando. En los comentarios del post inicial, veréis que también se discute este tema, y el autor del post, defiende que en estos casos es mejor no manejar dicha excepcion y dejar que la aplicación “explote” con el típico mensaje de windows y la posibilidad de enviar el registro a MS… En mi opinión, decidirlo vosotros según el sistema que estéis desarrollando y sus necesidades.

En resumen, creo que es buena práctica manejar las excepciones propias de las operaciones que estamos realizando, y dejar abierto a las necesidades del sistema, si queréis manejar fallos del sistema, o no. Como veréis, de nuevo en informática tiramos del principio del gallego… depende!! 🙂

Más info de interés al respecto:

Espero que os sirva!!

Saludos.

Anuncios

Throw o Throw Ex, esa es la cuestión

15 agosto 2009

Estaba revisando un artículo de code project (que no os enlazo porque es algo viejo y no creo que algunas de las cosas sean válidas hoy en día), cuando en un punto de dicho artículo menciona la diferencia de usar throw ex y/o sólo throw. Esto me ha hecho recordar que hace unos días, mi compi Jose Antonio (un crack!), me contó algo al respecto y me he decidido a indagar algo más.

De lo que he leído, os paso 2 enlaces muy buenos sobre el tema y en los que me he basado para este resumen.

http://geekswithblogs.net/sdorman/archive/2007/08/20/Difference-between-quotthrowquot-and-quotthrow-exquot-in-.NET.aspx

http://aspadvice.com/blogs/joteke/archive/2004/04/15/2277.aspx

Básicamente, lo que viene a decir es, que al usar throw ex, se hace un limpiado del Stack Trace, lo que hace que al llegar la excepción a la capa de arriba, ésta sólo contenga información en el stack trace, de la última excepción producida, y no “acarree” posible información de excepciones que se haya podido producir en otros métodos anteriores. Esto, que es algo complejo de explicar por escrito, lo podéis ver muy fácilmente en el ejemplo del segundo artículo, donde hay varias excepciones anidadas y se ve claramente que con throw Ex se pierde información, de los errores acumulados.

Algo similar ocurre cuando capturamos una excepción, pero lanzamos una nueva excepción personalizada. Ejm (copiado del primer artículo):
code1

Para evitar eso, a la hora de lanzar la excepción personalizada, se aconseja pasar como parámetro la excepción capturada:

throw new ApplicationException("operation failed!", ex);

Así que, como regla general (que no fija), mejor lanzar la excepción con Throw para tener la máxima información del Stack Trace 🙂

Para acabar, por si alguien dudaba de la importancia de manejar adecuadamente los errores de nuestra aplicación, aquí os dejo un par de imágenes curiosas:

Pantallazo azul a lo grande!!
error_azul

system_error
(Esta última, por increíble que parezca, tb es una historia real, podéis verlo aquí … flipo!…)

Saludos!!