winforms - Silent failures in C#, seemingly unhandled exceptions that does not crash the program -

In a winforms app, in the load event of a form, add the following line:

  Throw a new exception ();  

Run the application and ran without a problem. This is called a silent failure, you can try to add messageboxes before and after, and you will soon find out Instead of crashing the app, the details of the throw just out of the load event.

I'm sure there is no need to explain how it is ugly and dangerous.

I was still thinking behind this terrible behavior (probably in history) for reasons. I am convinced that this is not a design decision, maybe there is no alternative, or does anyone know laziness?

Would be happy if someone could point me in a list of events which could also cause failure failures.

This is the snippet of my code - I do not know how it can help - but, here it is:

  using the system; Using System.Collections.Generic; Using System.Linq; Using System.Windows.Forms; Namespace WindowsFormsApplication1 {Static class program {/// & lt; Summary & gt; Main entry point for the application /// & lt; / Summary & gt; [STAThread] static zero main () {form f = new form (); F.Load + = New EventHandler ((X, Y) => {New Exception ();}); Application.Run (f); }}}  

Edit It seems that it is not for everyone, I am with the above code: fw 3.5, winforms, vs 2008, vista Use the new clean project of X64, Winforms.

this is the one:

on this 64-bit OS platform There is a known issue. The reason for this is that the 64-bit OS core does not allow user mode exceptions via the kernel mode stack. The exception is swallowed by the OS. This is in the formalda handler because it is called in the callback. The 32bits OS does not do this, so there is no interference in it.

The OS team is investigating related issues. In time, you have to work around this issue. The debugger has to be stopped in this scenario by turning on "Stop the first chance exception". But this debugger has to be stopped very often, so you want to do it only when you get a problem.

The linked bug report was last updated on February 2008, and indicate what happened since.

I can reproduce the poster's behavior on my 32-bit system here, and I re-generate OP's behavior on my 64-bit (Vista SP2, 3.5SP1 Framework) PC I can do