views:

870

answers:

3

hi, have no idea what didn't you understand here:

http://stackoverflow.com/questions/1583124/what-is-the-origin-or-the-reason-or-silent-failures-closed

but i'm sorry anyway. i'll try to explain it again.

in a winforms app, in a form's Load event, add the following line:

  throw new Exception();

and run the application. it ran without a problem. this called a silent failure, you can try to add messageboxes before and after, and you'll soon find out that instead of crashing the application, the throw statement just exits from the Load event.

i'm sure there is no need to explain how ugly and dangerous this is.

i was wondering nonetheless in the (probably history) reasons behind this terrifying behavior. i'm sure it's not a design decistion, probably no-choice, or laziness. does anybody knows?

would be glad if anyone can point me to a list of events which may cause seilent failiures two.

thanks.

EDIT: i've been asked to a snippet of my code. honestly, guys, i have no idea how it helps you but, here the thing:

using System; using System.Collections.Generic; using System.Linq; using System.Windows.Forms;

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

    }
}

p.s. in my blindness i've just noticed that i was voted down 3 times in my last question (link in the start)... if any of you find this question okay (the first one), i would be happy if you help me get back my lost accept rate by voting it up :D

EDIT 2: O_o weired enough it seems it does not happend to everyone..

i use: fw 3.5, winforms, vs 2008, vista x64, new clean project of winforms, with the code mentioned above.

A: 

Is this only if the form is the target of Application.Run? I have the need to through exceptions in form load events and I haven't run into the issue you are speaking of. It sounds like it could be circumstantial to the conditions of the form invocation.

Quintin Robinson
A: 

I think you've surrounded your Application.Run with a try..catch block. You should show the entire code of your application.

edit: even with the code provided by the op, I still think theres a try..catch block he's not showing (or an unhandled exception handler), because it should (and does) crash when the form loads.

Blindy
hold on a minute, do you think i censored my code? :D i have opened a new project, and try this exact code.
Itay
I did try it and it worked fine (ie it error'd out on an uncaught exception), but I have a 32 bit system so /shrug
Blindy
+18  A: 

This is a known problem on x64 systems:

This is a known issue on 64-bit OS platform. The reason is that the 64bit OS core does not allow user mode exception through kernal mode stacks. The exception is swallowed by OS sliently. That happens in FormLoad handler, because it is called in an OS callback. 32bits OS doesn't do this, so it doesn't repro there.

The OS team is investigating related issues. In the mean time, you do have to work around this issue. Turning on "Stop on first chance exception" will make the debugger to stop in this scenario. But it does make the debugger to stop very often, so you might want to do this only when you find a problem.

The linked bug report was last updated February 2008, and doesn't indicate what's happened since then.

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

Michael Petrotta
thanks a lot.. i half remember this happened to me as well with x86, but i'm not sure enough.. i'll check it out.
Itay
Interestingly, this exception is not swallowed on my Windows 7 x64 machine when I run without debugging, but is swallowed when I do.
FacticiusVir
@FacticiusVir: Exactly the same here. On my Win7 x64 it is swallowed only when I'm in the VS debugging mode.
ulrichb