Fallas silenciosas en C #, excepciones aparentemente no controladas que no bloquean el progtwig

En una aplicación de winforms, en el evento Load de un formulario, agregue la siguiente línea:

throw new Exception(); 

y ejecuta la aplicación. Corrió sin problemas. Esto se llama falla silenciosa, puede intentar agregar cuadros de mensaje antes y después, y pronto descubrirá que en lugar de bloquear la aplicación, la instrucción throw simplemente sale del evento Load.

Estoy seguro de que no hay necesidad de explicar qué tan feo y peligroso es esto.

Me preguntaba, sin embargo, en las razones (probablemente históricas) detrás de este comportamiento aterrador. Estoy seguro de que no es una decisión de diseño, probablemente sin opción, o flojera. ¿Alguien sabe?

Estaría contento de que alguien me señale una lista de eventos que también pueden causar fallas graves.

Aquí hay un fragmento de mi código, no tengo idea de cómo podría ayudar, pero aquí está:

 using System; using System.Collections.Generic; using System.Linq; using System.Windows.Forms; namespace WindowsFormsApplication1 { static class Program { ///  /// The main entry point for the application. ///  [STAThread] static void Main() { Form f = new Form(); f.Load += new EventHandler((x, y) => { throw new Exception(); }); Application.Run(f); } } } 

EDITAR Parece que no sucede a todos. Uso: fw 3.5, winforms, vs 2008, vista x64, nuevo proyecto limpio de winforms, con el código mencionado anteriormente.

Este es un problema conocido en los sistemas x64 :

Este es un problema conocido en la plataforma del sistema operativo de 64 bits. El motivo es que el núcleo del sistema operativo de 64 bits no permite la excepción de modo de usuario a través de stacks de modo Kernal. La excepción es tragada por OS sliently. Eso sucede en el controlador de FormLoad, porque se llama en una callback del sistema operativo. El sistema operativo de 32 bits no hace esto, por lo que no reproduce allí.

El equipo del sistema operativo está investigando problemas relacionados. Mientras tanto, tienes que evitar este problema. Si activa la opción “Detener en primera oportunidad”, el depurador se detendrá en este escenario. Pero hace que el depurador se pare muy a menudo, por lo que es posible que desee hacer esto solo cuando encuentre un problema.

El informe de error vinculado se actualizó por última vez en febrero de 2008 y no indica lo que sucedió desde entonces.

Aquí puedo reproducir el comportamiento de la mayoría de los carteles en mi sistema de 32 bits, y puedo reproducir el comportamiento del OP en mi PC de trabajo de 64 bits (Vista SP2, 3.5SP1 Framework).