¿Cuándo se puede comer una excepción en una aplicación .NET WinForms sin ser atrapada o burbujeando a una excepción de Windows?

Question

En varios lugares de nuestro código, notamos que si se ejecuta bajo el depurador, mostrará que hay una excepción no controlada en el código, sin embargo, si se ejecuta fuera del depurador, simplemente ignorará la excepción por completo como si hubiera sido detectada. Tenemos un controlador de excepciones que muestra un cuadro de diálogo de envío de error que está conectado a Application.ThreadException y AppDomain.CurrentDomain.UnhandledException Y ninguno de los dos parece estar atrapándolos tampoco. También registramos nuestras excepciones y no aparece nada en el registro.

¿Cuáles son algunas posibles razones para esto?

Editar: Parece que no depende del tipo de lanzamiento de excepción, sino más bien de dónde se lanza. Esto se probó simplemente agregando:

throw new Exception("Test Exception");

Aparecerá debajo del depurador pero no aparecerá afuera, por lo que en nuestro caso no es una ThreadAbortedException ni nada que dependa de que sea un tipo específico de excepción.

Answer 1

Encontramos un lugar donde esto podría ocurrir si hay una excepción en el controlador de eventos UnhandledException. Una manera fácil de ver esto es esto: En el controlador de eventos Form.Load, arroje cualquier excepción anterior. En el evento Application.ThreadException, coloque algo similar a lo siguiente:

static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
     string b = null;
     int i = b.Length;
}

En el depurador, mostrará que su excepción no fue controlada por el código de usuario, y luego mostrará una excepción de referencia nula en el controlador ThreadException, pero si la ejecuta fuera del depurador, se tragará la excepción como fue manejado.

Answer 2

Hay algunas excepciones especiales que no se burbujean o atrapan, parece que está tratando con uno de ellos: consulte ThreadAbortException

Answer 3

Si intenta modificar las propiedades de un control de Windows Form desde un subproceso diferente en el que se creó el control, obtendrá un InvalidOperationException si hay un depurador conectado, pero de lo contrario se ignora en silencio.

Puede encontrar más información sobre el problema aquí:

http://msdn.microsoft.com/ es-es / library / ms171728 (VS.80) .aspx

Answer 4

Su código se invoca desde el marco.

A veces, el marco envuelve sus llamadas en un controlador de excepciones.

Entonces, si hay una excepción en su código, puede ser (si hay un controlador de excepciones allí en el marco) capturado e ignorado por el marco.

Tal vez el depurador lo muestre como " no controlado " porque, aunque hay un controlador en el marco, ¿no hay un controlador en su código? ¿O porque hay algo extraño sobre el controlador en el marco, por ejemplo, que es un controlador de excepciones estructurado y no administrado?

Answer 5

¿Está utilizando .Net 1.0 / 1.1? Hubo un gran cambio en el comportamiento en la transición de 1.1 a 2.0. Antes de eso, las excepciones generadas en los hilos que creó o los hilos de ThreadPool serían tragados en silencio por el frameworok y el hilo saldría. Afortunadamente, este comportamiento ahora se ha solucionado.

De MSDN :

  

Cambio de versiones anteriores

     

El cambio más significativo pertenece   a hilos gestionados. En la red   Framework versiones 1.0 y 1.1, el   Common Language Runtime proporciona un   respaldo para excepciones no controladas en   las siguientes situaciones:

     

  

• No hay tal cosa como un no manejado   excepción en un subproceso de grupo de subprocesos.   Cuando una tarea arroja una excepción que   no maneja, el tiempo de ejecución imprime   el rastro de la pila de excepción a la   consola y luego devuelve el hilo a   el grupo de hilos.

  

• No hay tal cosa como un no manejado   excepción en un hilo creado con el   Método de inicio de la clase Thread. Cuando   código que se ejecuta en tales lanzamientos de hilo   una excepción que no maneja,   el tiempo de ejecución imprime la pila de excepciones   rastrear a la consola y luego   termina con gracia el hilo.

  

• No hay tal cosa como un no manejado   excepción en el hilo finalizador.   Cuando un finalizador lanza una excepción   que no maneja, el tiempo de ejecución   imprime el seguimiento de la pila de excepción en   la consola y luego permite   hilo finalizador para reanudar la ejecución   finalizadores.

  

Answer 6

Es un poco difícil aquí, pero ¿podría ser que acaba de configurar su depurador para que se rompa cuando se lanza una excepción, y no solo para los no manejados?