Unhandled exceptions on Model Form remains unhandled in the release build even if the call to the model form is wrapped up in the try….catch{ } block!!!!!!

Cracked Down

Hi all, I have found this some unusual problem while working on the debug and release build. I have two forms MainForm and ModelForm. Following is the code for these respective forms .cs files Code for MainForm.cs :

namespace ModelDialogExceptions
{
public partial class MainForm : Form
{
public Form1()
{
InitializeComponent();
}

    private void button1\_Click(object sender, EventArgs e)
    {
        try
        {
            ModelDialog mdl = new ModelDialog();
            mdl.ShowDialog(); 
        }
        catch (Exception exc)// caught only in the Debug build
        {
            MessageBox.Show("Exception captured!!!");
        }
    }
}

}

And code for ModelForm.cs :

namespace ModelDialogExceptions
{
public partial class ModelDialog : Form
{
public ModelDialog()
{
InitializeComponent();
}

    private void button1\_Click(object sender, EventArgs e)
    {
        throw new System.IO.FileNotFoundException("");
    }
}

}

If I run this project in debug build, message box gets poped up however, in the Release (when i run output .exe in) build an unhandeled exception is raised. Any body know, why this code is behaving differently for different builds? or any comments about this!!

Christian Graus

You can add a top level exception handler, which will catch exceptions from other threads. Why you have this difference, I don't know.

Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.

Luc Pattyn

1. debug and release EXE files are stored in different folders 2. your "current directory" initially is set to the folder containing the EXE 3. you forgot to copy the file your app wants from your debug folder to your release folder, so the debug version finds it, the release version does not. :)

Luc Pattyn [Forum Guidelines] [My Articles]

The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.

Christian Graus

I don't read his code that he's looking for any file at all, he's just playing with exceptions. But, if he failed to post most of his code, then you're probably right. A try/catch that then throws a FileNotFoundException is a bit retarded, tho

Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.

Cracked Down

I guess top level exception handler wont be useful as application is going to shut down anyway!! it will be just more or less equals to saying "good bye"!! some additional info: actually this difference is not related to debug or release(sorry for previous info- i just got this difference) instead it is in between output .exe (both in debug and release) and visual studio code,when i run from the visusal studio i gets the message box

Cracked Down

no guys! i am not at all playing with files! that was just for demonstration instead of throwing FileNotFoundException I can throw any Exception

Christian Graus

That's what I thought

Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.

Moreno Airoldi

The code you showed works perfectly fine, so you either omitted something or you have a problem with your VS and/or .NET framework, in which case you should re-install it all. Unless there's a problem with your CPU or your Win... I really think you omitted something. ;)

2+2=5 for very large amounts of 2 (always loved that one hehe!)

Cracked Down

have you tried running .exe file generated in debug/release directory under bin directory. if you tried then i will have to follow what you are saying otherwise please try running the .exe and let me know the resust thanks in advance!

Moreno Airoldi

Sorry I think I didn't make myself clear: what I mean is it's perfectly normal that the application, when run directly (i.e. running the exe file) crashes. But this will happen for both Debug and Release! If you run the app inside the VS debugger, on the contrary, then it will behave differently: both Debug and Release versions will catch the exception and show the dialog box. This happens because exception handling is slightly different while running the debugger. Just to be sure I made the experiment myself just now, and I confirm what I said. In order to capture the exception you must use a local try/catch block in the ModelDialog form. There is no way I know of handling the exception the way you want to. I suggest your change your approach. Consider this (just a raw example):

namespace ModelDialogExceptions
{
public partial class ModelDialog : Form
{
public ModelDialog()
{
InitializeComponent();
}

    private void button1\_Click(object sender, EventArgs e)
    {
        try
        {
            // this is just for test, of course
            throw new System.IO.FileNotFoundException("");

            // when all is fine...
            DialogResult = DialogResult.OK;
        }
        catch (Exception)
        {
            // when it goes wrong...
            DialogResult = DialogResult.Abort;
        }
    }

    internal static bool GetMyFile()
    {
        ModelDialog md = new ModelDialog();
        switch (md.ShowDialog())
        {
            case DialogResult.OK:
                return true;
            case DialogResult.Abort:
                throw new ApplicationException("Operation aborted, an exception may have been thrown.");
            case DialogResult.Cancel:
                throw new ApplicationException("Cancelled by user.");
            default:
                throw new ApplicationException("Unknown error.");
        }
    }
}

}

namespace ModelDialogExceptions
{
public partial class MainForm : Form
{
public MainForm()
{
InitializeComponent();
}

    private void button1\_Click(object sender, EventArgs e)
    {
        try
        {
            if (ModelDialog.GetMyFile())
            {
                MessageBox

Cracked Down

thanks for such wonderful reply!! You know what I did the same (Because didnt had any other alternative) I thought I could share you with you all guys this unusual behavior, might be somebody knowing the exactly why this happens? anyways thanks for reply!

Moreno Airoldi

As I said, it happens because of the debugger. The debugger contains an exception handler which "watches" for exceptions while running the code. When an exception is caught, it will walk up not only the function call stack (which is what the runtime does when you run the exe), but the program flow - searching for a try/catch block which can catch the exception. If it's not found, then the debugger's handler kicks in (it's the piece of code that shows you the exception message box and lets you point at the code which raised it). Now, calling ShowDialog() is not like calling any other function. A normal function call will just transfer the current thread's execution to the function's code, saving the return address on the stack, and return to the calling code when the function exits. This allows for the raised exception to be passed directly up to the calling code and get caught by the upper level try/catch block. What happens when you call ShowDialog() is that the new form is created and shown, and the UI's message pump (remember it all runs on a single thread, but it's message-based) starts managing it together with all other open forms, with the only exception that other forms will be "frozen". When the dialog closes and returns its result, this is passed back to the calling code, and execution flow returns there, but in this case exceptions do not cross the boundaries of forms, since there's no "bridging" code for that to happen. This is the best explanation I can give, I hope it clears your doubts. Maybe some other guy can give a more complete or deeper explanation. :)

2+2=5 for very large amounts of 2 (always loved that one hehe!)

Cracked Down

Yeh Moreno Airoldi !!!! that was great info !!! thanks a ton for such nice explanation!!

Moreno Airoldi

My pleasure. :)

2+2=5 for very large amounts of 2 (always loved that one hehe!)