jueves, 22 de noviembre de 2012

Visual Studio no lanza todas las excepciones del código

Hoy me ha pasado una cosa un poco extraña relacionada con la gestión de excepciones.

El problema

Tenemos un formulario de Windows con una caja de texto en la que en el evento “TextChanged” realizamos una serie de operaciones, llamando para ello a un método externo.

El tema es que en un momento dado, me he fijado que en el método externo se estaba produciendo una excepción, pero en depuración no me estaba mostrando la típica ventana de excepción no controlada… Vamos, que no me estaba enterando de que había un problema con el código.

Para reproducir este comportamiento, basta con añadir una caja de texto a un formulario y codificar en el manejador del evento “TextChanged” una llamada a una función que produzca una excepción, por ejemplo:

image

Ejecutamos el formulario y escribimos algo en la caja de texto.

¿Aparece esta ventana?

image

Entonces no tienes el mismo problema que yo y te has equivocado de post…

Lo que a mí me pasaba, es… nada. No da ningún tipo de excepción al trabajar con el formulario en cuestión. entonces, ¿cómo sabemos que hay una excepción? en la ventana de “Output” aparece la siguiente entrada:

image

Una explicación (rapidita)

Por lo visto, este comportamiento es así por diseño, siempre que estemos ejecutando Visual Studio en un sistema en 64 Bits (como es mi caso) cuando la excepción se produce en un método que cause una transición al kernel (como por ejemplo el manejador en cuestión, esta excepción se trata en el propio kernel y se atrapa por el sistema operativo. Como la excepción ya ha sido controlada, lo que sucede es que nosotros no nos enteramos.

Para más detalle, entiendo que Google estará encantado de ayudarnos.

Una solución (más bien alternativa)

Para conseguir que el depurador de Visual Studio nos avise de esas excepciones, tenemos que indicarle explícitamente, en la ventana de “Exceptions”

image

Esta ventana aparece en el menú “Debug”, “Exceptions…” y para evitar el comportamiento que he explicado, basta con marcar la casilla “Thrown” del grupo “Common Language Runtime Exceptions”

Una vez marcada la casilla, cuando llega al punto de la excepción, ya nos aparece la ventana de excepción no controlada que necesitamos. De esta manera ya no se nos “enmascaran” posibles errores…

¿Por qué digo que es una alternativa?

Un efecto colateral de esta configuración es que a partir de activar la opción, cada vez que de una excepción (sea controlada o no) nos va a aparecer la dichosa ventanita, deteniendo el depurador hasta que le demos a continuar.

Esto en condiciones normales es un auténtico problema, pero yo considero que me merece la pena el inconveniente, sobre todo si trabajamos con ‘rethrowing’

Último apunte

El problema expuesto aquí no genera ningún problema adicional en el código desarrollado, ya que si en lugar de arrancar el depurador ejecutamos el archivo compilado o lanzamos la ejecución SIN depuración (Ctrl + F5) la excepción no controlada SÍ que aparece aunque, claro, con la apariencia que nadie queremos en nuestros programas

image

1 comentario:

Anónimo dijo...

Excelente aporte, me sirvió mucho, gracias