Tryブロックで値を返すと、Finallyステートメントのコードが起動しますか？

私は友人のコードをレビューしていて、彼がtry-finallyブロック内でreturnステートメントを使用していたと言います。最後のセクションのコードは、tryブロックの残りの部分が実行されなくても実行されますか？

例：

public bool someMethod()
{
  try
  {
    return true;
    throw new Exception("test"); // doesn't seem to get executed
  }
  finally
  {
    //code in question
  }
}

簡単な答え：はい。

通常、はい。finallyセクションは、例外やreturnステートメントを含め、何が起こっても実行することが保証されています。このルールの例外は、スレッドで発生する非同期例外（OutOfMemoryException、StackOverflowException）でです。

そのような状況での非同期例外と信頼性の高いコードの詳細については、制約付き実行領域についての説明をご覧ください。

ここに小さなテストがあります：

class Class1
{
    [STAThread]
    static void Main(string[] args)
    {
        Console.WriteLine("before");
        Console.WriteLine(test());
        Console.WriteLine("after");
    }

    static string test()
    {
        try
        {
            return "return";
        }
        finally
        {
            Console.WriteLine("finally");
        }
    }
}

結果は次のとおりです。

before
finally
return
after

MSDNからの引用

最後に、前のtryブロックの終了方法に関係なく、コードのステートメントブロックの実行を保証するために使用されます。

一般的にはい、最終的に実行されます。

次の3つのシナリオでは、finallyは常に実行されます。

1. 例外は発生しません
2. 同期例外（通常のプログラムフローで発生する例外）。
   これには、System.Exceptionから派生するCLS準拠の例外と、System.Exceptionから派生しないCLS準拠以外の例外が含まれます。CLSに準拠していない例外は、RuntimeWrappedExceptionによって自動的にラップされます。C＃ではCLS以外のクレーム例外をスローできませんが、C ++などの言語ではスローできます。C＃は、CLSに準拠しない例外をスローできる言語で記述されたコードを呼び出す可能性があります。
3. 非同期ThreadAbortException
   .NET 2.0以降、ThreadAbortExceptionは、finallyの実行を妨げなくなりました。ThreadAbortExceptionは、finallyの前または後にホイストされるようになりました。finallyは常に実行され、スレッドの中止が発生する前に試行が実際に入力されている限り、スレッドの中止によって中断されることはありません。

次のシナリオでは、finallyは実行されません。

非同期StackOverflowException。
.NET 2.0以降、スタックオーバーフローによりプロセスが終了します。さらに制約を適用して最終的にCER（制約付き実行領域）にしない限り、finallyは実行されません。CERは、一般的なユーザーコードでは使用しないでください。これらは、クリーンアップコードを常に実行することが重要な場合にのみ使用してください。すべてのプロセスがスタックオーバーフローでシャットダウンされ、すべての管理対象オブジェクトがデフォルトでクリーンアップされます。したがって、CERが関連する唯一の場所は、管理されていないハンドルなど、プロセスの外部に割り当てられたリソースの場合です。

通常、アンマネージコードは、ユーザーコードによって使用される前に、マネージクラスによってラップされます。マネージラッパークラスは、通常、SafeHandleを使用してアンマネージハンドルをラップします。SafeHandleは、重要なファイナライザと、クリーンアップコードの実行を保証するためにCERで実行されるReleaseメソッドを実装します。このため、CERがユーザーコード全体に散らばって表示されることはありません。

したがって、プロセスがとにかく終了するため、finallyがStackOverflowExceptionで実行されないという事実は、ユーザーコードに影響を与えません。SafeHandleまたはCriticalFinalizerObjectの外でアンマネージリソースをクリーンアップする必要がある特別なケースがある場合は、次のようにCERを使用します。ただし、これは悪い習慣です。アンマネージドコンセプトは、マネージドクラスと適切なSafeHandleに設計によって抽象化する必要があります。

例えば、

// No code can appear after this line, before the try
RuntimeHelpers.PrepareConstrainedRegions();
try
{ 
    // This is *NOT* a CER
}
finally
{
    // This is a CER; guaranteed to run, if the try was entered, 
    // even if a StackOverflowException occurs.
}

これには非常に重要な例外があり、他の回答では言及されていません。また、（C＃で18年間プログラミングした後）知らなかったなんて信じられません。

（奇妙なものやその類のものだけでなく）ブロック内で何らかの種類の例外をスローまたはトリガーし、catchブロックStackOverflowExceptions全体try/catch/finallyが別のtry/catchブロック内finallyにない場合、ブロックは実行されません。これは簡単に示されます-そして、私がそれを自分で見ていなかった場合、finallyブロックが実行されない可能性があるのは本当に奇妙な小さなコーナーケースだと何度も読んだことを考えると、私はそれを信じていませんでした。

static void Main(string[] args)
{
    Console.WriteLine("Beginning demo of how finally clause doesn't get executed");
    try
    {
        Console.WriteLine("Inside try but before exception.");
        throw new Exception("Exception #1");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"Inside catch for the exception '{ex.Message}' (before throwing another exception).");
        throw;
    }
    finally
    {
        Console.WriteLine("This never gets executed, and that seems very, very wrong.");
    }

    Console.WriteLine("This never gets executed, but I wasn't expecting it to."); 
    Console.ReadLine();
}

これには理由があると思いますが、あまり知られていないのは奇妙です。（たとえば、ここでは注記されていますが、この特定の質問のどこにも記載されていません。）

私はパーティーに遅れていることを認識していますが、実際に例外がスローされるシナリオ（OPの例とは異なります）では、MSDNの状態（https://msdn.microsoft.com/en-us/library/zwc8s4fz.aspx）：「例外がキャッチされない場合、finallyブロックの実行は、オペレーティングシステムが例外の巻き戻し操作をトリガーするかどうかによって異なります。」

finallyブロックは、呼び出しスタックのさらに上にある他の関数（Mainなど）が例外をキャッチした場合にのみ実行が保証されます。すべてのランタイム環境（CLRとOS）のC＃プログラムは、プロセスが終了したときに所有するほとんどのリソース（ファイルハンドルなど）で実行されるため、通常、この詳細は問題になりません。ただし、場合によっては、それが非常に重要になることもあります。くつろぐ。または、OSによって自動的に閉じられず、サーバーをブロックするリモート接続。

はい。それが事実、finallyステートメントの主要なポイントです。（メモリ不足、コンピューターのプラグが外れているなど）何か異変が発生しない限り、finallyステートメントは常に実行する必要があります。

また、キャッチされない例外や、Windowsサービスでホストされているスレッドで実行されている場合も起動しません。

最後に、Windowsサービスで実行されているスレッドでは実行されません

System.exit（0）;を使用してアプリケーションを終了している場合、最終的には実行されません。のように

try
{
    System.out.println("try");
    System.exit(0);
}
finally
{
   System.out.println("finally");
}

結果は次のようになります：試してください

シナリオの99％では、finallyブロック内のコードが実行されることが保証されますが、次のシナリオを考えてください。スレッドにtry-> finallyブロック（なしcatch）があり、そのスレッド内で未処理の例外が発生します。この場合、スレッドは終了し、そのfinallyブロックは実行されません（この場合、アプリケーションは引き続き実行できます）

このシナリオはかなりまれですが、答えが常に「はい」ではないことを示すためだけであり、ほとんどの場合「はい」であり、まれに、「いいえ」の場合もあります。

finallyブロックの主な目的は、その中に記述されているものを実行することです。tryまたはcatchで発生したことには依存しません。ただし、System.Environment.Exit（1）を使用すると、アプリケーションは次のコード行に移動せずに終了します。