finally block in c#

Question

Possible Duplicate:
Finally Block Not Running??

I have a question regarding finally block in c#. I wrote a small sample code:

public class MyType
{
    public void foo()
    {
        try
        {
            Console.WriteLine("Throw NullReferenceException?");
            string s = Console.ReadLine();
            if (s == "Y")
                throw new NullReferenceException();
            else
                throw new ArgumentException();          
        }
        catch (NullReferenceException)
        {
            Console.WriteLine("NullReferenceException was caught!");
        }
        finally
        {
            Console.WriteLine("finally block");
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        MyType t = new MyType();
        t.foo();
    }
}

As I far as I know, finally block suppose to run deterministicly, whether or not an exception was thrown. Now, if the user enters "Y" - NullReferenceException is thrown, execution moves to the catch clock and then to the finally block as I expected. But if the input is something else - ArgumentException is thrown. There is no suitable catch block to catch this exception, so I thought execution should move the the finally block - but it doesnt. Could someone please explain me why?

thanks everyone :)

possible duplicate: http://stackoverflow.com/questions/4193493/finally-block-not-running — Matt Ellen, Feb 01 '11 at 08:38
I've tried the code, and it enters the finally block as expected — SWeko, Feb 01 '11 at 08:39
Can you clarify what you mean by ` I thought execution should move the the finally block` - I presume the control is going into the finally in both cases - right? — Jagmag, Feb 01 '11 at 08:40
Yes, apparently it actually does enter the finally block, and i miss that because of the debugger... :| — meem, Feb 01 '11 at 08:52

bitxwise · Accepted Answer · 2011-02-01T08:47:22.263

6

Your debugger is probably catching the ArgumentException so it's waiting for you to "handle" it there before entering the final block. Run your code w/o an attached debugger (including w/o your JIT debugger) and it should hit your finally block.

To disable JIT, go to Options > Tools > Debugging > Just-In-Time and uncheck Managed

To debug w/o an attached debugger, in Visual Studio go to Debug > Start Without Debugging (or CTRL + F5)

It would also be helpful to put a Console.ReadLine() at the end of your program to prevent the console from closing after entering your finally block.

class Program {
    static void Main(string[] args) {
        MyType t = new MyType();
        t.foo();
        Console.ReadLine();
    }
}

Here is the output you should get:

Throw NullReferenceException? N

Unhandled Exception: System.ArgumentException: Value does not fall within the ex pected range.

at ConsoleSandbox.MyType.foo() in P:\Documents\Sandbox\Console\Console\Consol e\Program.cs:line 17

at ConsoleSandbox.Program.Main(String[] args) in P:\Documents\Sandbox\Console \Console\Console\Program.cs:line 31

finally block

Press any key to continue . . .

edited Feb 01 '11 at 08:47

answered Feb 01 '11 at 08:41

bitxwise

3,534
2
17
22

Well, you are right. I didnt think it is related to the debugger because I tried all 4 combinations of the 'Thrown' and 'User-Unhandled' of the CLR Runtime Exceptions in the Exception window. Isnt that related? I mean, if I unchecked those boxes, shouldnt the code run with no interference? Thanks again, for you time. – meem Feb 01 '11 at 08:50
You're referring to the [Debug > Exceptions] options; that's different from the Just-In-Time debugger options I mentioned above. The JIT debugger will catch UNHANDLED exceptions whereas the exceptions options you're referring to is Visual Studio's attached debugger. – bitxwise Feb 01 '11 at 08:57
Just thought I'd mention that Henk Holterman is also correct and surrounding your t.foo() call w/ a try/catch will show that your finally block is indeed called - but that changes your scenario in that your ArgumentException becomes a handled exception and the JIT debugger doesn't make it look like your finally block isn't being called anymore. This is why we should always handle our exceptions =) – bitxwise Feb 01 '11 at 09:01
I agree that my code is indeed a bad practice. It was written for learning purpose only. – meem Feb 01 '11 at 09:06

score 1 · Answer 2 · answered Feb 01 '11 at 08:52

What you see is an artifact of your test program.

If you change your main method:

 static void Main(string[] args)
 {
    try
    {
        MyType t = new MyType();
        t.foo();
    }
    catch
    {
       // write something
    }
 }

Then your foo() will behave as expected.

Without that toplevel try/catch, your entire program was being aborted.

finally block in c#

2 Answers2