5

Another interview question which was expecting a true / false answer and I wasn't too sure.

Duplicate


10 답변


26

finally is executed most of the time. It's almost all cases. For instance, if an async exception (like StackOverflowException, OutOfMemoryException, ThreadAbortException) is thrown on the thread, finally execution is not guaranteed. This is why constrained execution regions exist for writing highly reliable code.

For interview purposes, I expect the answer to this question to be false (I won't guarantee anything! The interviewer might not know this herself!).


  • Very interesting, never heard of CERs before. Thanks for raising it here. - Colin Desmond
  • +1 This is an often-missed and very important point! It is dangerous to say that "finally" always executes for the reasons you point out. Nice answer. - Andrew Hare
  • Completely agreed. I think the source of the problem is MSDN itself. It should increase awareness of this fact in links such as the one mentioned in the accepted answer. When MSDN itself says.. "finally is used to guarantee a statement block of code executes regardless of how the preceding try block is exited" which is wrong, this will be the result. I know very few people who don't answer yes to this question. - Mehrdad Afshari
  • I see someones been doing their homework, great answer! A very interesting article too. - John T
  • Also don't forget the much more common cases where it doesn't execute because the power went out, the hardware malfunctioned, the OS killed the process, etc. If you've half-finished writing a sensitive file and the OS kills you, the finally block won't save you. - Craig Gidney

7

Generally the finally block is guaranteed to execute.

However, a few cases forces the CLR to shutdown in case of an error. In those cases, the finally block is not run.

One such example is in the presence of a StackOverflow exception.

E.g. in the code below the finally block is not executed.

static void Main(string[] args) {
   try {
      Foo(1);
   } catch {
      Console.WriteLine("catch");
   } finally {
      Console.WriteLine("finally");
   }
}

public static int Foo(int i) {
   return Foo(i + 1);
}

The other case I am aware of is if a finalizer throws an exception. In that case the process is terminated immediately as well, and thus the guarantee doesn't apply.

The code below illustrates the problem

static void Main(string[] args) {
   try {
      DisposableType d = new DisposableType();
      d.Dispose();
      d = null;
      GC.Collect();
      GC.WaitForPendingFinalizers();
   } catch {
      Console.WriteLine("catch");
   } finally {
      Console.WriteLine("finally");
   }
}

public class DisposableType : IDisposable {
   public void Dispose() {
   }

   ~DisposableType() {
      throw new NotImplementedException();
   }
}

In both cases the process terminates before both catch and finally.

I'll admit that the examples are very contrived, but they are just made to illustrate the point.

Fortunately neither happens very often.


  • Interesting point, but it should probably be noted that the second example doesn’t catch the exception because it occurred on a different/unprotected thread. - Matthew Whited
  • +1 for using a StackOverflow as an example :-) - Josh

6

Straight from MSDN:

The finally block is useful for cleaning up any resources allocated in the try block. Control is always passed to the finally block regardless of how the try block exits.

Whereas catch is used to handle exceptions that occur in a statement block, finally is used to guarantee a statement block of code executes regardless of how the preceding try block is exited.

http://msdn.microsoft.com/en-us/library/zwc8s4fz(VS.71,loband).aspx



3

Yes, finally is always executed.


3

It is not totally true that finally will always be executed. See this answer from Haacked:

Two possibilities:

  • StackOverflowException
  • ExecutingEngineException

The finally block will not be executed when there's a StackOverflowException since there's no room on the stack to even execute any more code. It will also not be called when there's an ExecutingEngineException, which is very rare.

However, these two exceptions are exception you cannot recover from, so basically your process will exit anyway.

As mentioned by Mehrdad, a reliable try/catch/finally will have to use Constrained Execution Regions (CER). An example is provided by MSDN:

[StructLayout(LayoutKind.Sequential)]
struct MyStruct
{
    public IntPtr m_outputHandle;
}

sealed class MySafeHandle : SafeHandle
{
    // Called by P/Invoke when returning SafeHandles
    public MySafeHandle()
        : base(IntPtr.Zero, true)
    {
    }

    public MySafeHandle AllocateHandle()
    {
        // Allocate SafeHandle first to avoid failure later.
        MySafeHandle sh = new MySafeHandle();

        RuntimeHelpers.PrepareConstrainedRegions();
        try { }
        finally
        {
            MyStruct myStruct = new MyStruct();
            NativeAllocateHandle(ref myStruct);
            sh.SetHandle(myStruct.m_outputHandle);
        }

        return sh;
    }
}


1

Generally the finally block is always executed regardless of whether an exception is thrown or not and whether any exception is handled or not.

There are a couple of exceptions (see other answers for more details).


0

'Finally' is executed regardless of whether an exception is thrown or not.

Its a good place to close any open connections. Successful or failed execution, you can still manage your connections or open files.


-1

Finally will happen everytime for that try catch block


-1

Finally block is guaranteed to be executed in any case.


-1

Finally is always executed. I not depends on how the try block works. If u have to do some extra work for both try and cath, it is better to put in finally block. So you can gurantee that it is always executed.

Linked


Related

Latest