なぜfinallyブロックを使用するのですか？

私の知る限り、次のコードスニペットはどちらも同じ目的を果たします。なぜfinallyブロックがあるのですか？

コードA：

try { /* Some code */ }
catch { /* Exception handling code */ }
finally { /* Cleanup code */ }

コードB：

try { /* Some code */ }
catch { /* Exception handling code */ }
// Cleanup code

• 処理していない例外がスローされた場合はどうなりますか？（私はあなたが捕まえていないことを願っていますThrowable...）
• tryブロックの内側から戻るとどうなりますか？
• catchブロックが例外をスローするとどうなりますか？

finallyブロックは確認しますが、あなたが（明示的に全体のプロセスを中止するいくつかの方法を法）そのブロックを終了し、それが実行されます。これは、リソースの決定論的なクリーンアップにとって重要です。

（少なくともJavaでは、おそらくC＃でも）tryブロックを。なしでcatch、ただしfinally。付きにすることも可能であることに注意してください。tryブロックで例外が発生すると、例外がfinally上位にスローされる前に、ブロック内のコードが実行されます。

InputStream in = new FileInputStream("somefile.xyz");
try {
    somethingThatMightThrowAnException();
}
finally {
    // cleanup here
    in.close();
}

tryまたはcatchブロックで何が起こっているかに関係なく、とにかく実行したいコードを配置することをお勧めします。

また、複数のcatchを使用していて、すべてのcatchブロックに共通のコードを配置する場合は、これを配置する場所になりますが、tryのコード全体が実行されたかどうかを確認することはできません。

例えば：

conn c1 = new connection();
try {
    c1.dosomething();
} catch (ExceptionA exa) {
    handleexA();
    //c1.close();
} catch (ExceptionB exb) {
    handleexB();
    //c1.close();
} finally {
    c1.close();
}

最後に、常に実行されますが、キャッチ後のコードは実行されない場合があります。

アプリケーションが強制的に閉じられても、実行する必要のあるタスクがいくつかあります（メモリの解放、データベースの閉じ、ロックの解放など）。これらのコード行をfinallyブロックに書き込むと、例外がスローされるかどうかに関係なく実行されます。ない...

アプリケーションはスレッドのコレクションである可能性があり、スレッドをException終了しますが、アプリケーション全体ではない場合finallyがあります。この場合、より便利です。

finallyJVMの失敗、スレッドの終了など、実行されない場合があります。

スローされる可能性のある例外に関係なく実行するには、そのコードが必要だからです。たとえば、管理されていないリソースをクリーンアップする必要がある場合があります（ 'using'コンストラクトはtry / finallyブロックにコンパイルされます）。

何があってもコードを実行したい場合があります。例外がスローされるかどうか。次に、を使用しfinallyます。

finally JVMがシャットダウンされない限り、常に実行されます。 finallyますが、クリーンアップコードを1か所に配置する方法を提供するだけです。

各catchブロックにクリーンアップコードを配置する必要があるとしたら、面倒です。

catchブロックが例外をスローした場合、残りのコードは実行されないため、finallyブロックを作成する必要があります。

最後に、Javaのブロックを使用して、ファイルのクローズ、接続のクローズなどの「クリーンアップ」コードを配置できます。

プログラムが終了した場合（System.exit（）を呼び出すか、プロセスを中止させる致命的なエラーが発生した場合）、finallyブロックは実行されません。

まだ下にスクロールしますか？どうぞ！

この質問は私にしばらく前に大変な時間を与えました。

try
{
 int a=1;
 int b=0;
 int c=a/b;
}
catch(Exception ex)
{
 console.writeline(ex.Message);
}
finally
{
 console.writeline("Finally block");
}
console.writeline("After finally");

上記のシナリオでは何が印刷されますか？はい、それは正しいと思いました：

• ex.Message--それが何であれ（おそらくゼロ除算を試みた）

• 最後にブロックする

• ついに

  try
  {
      int a=1;
      int b=0;
      int c=a/b;
  }
  catch(Exception ex)
  {
      throw(ex);
  }
  finally
  {
      console.writeline("Finally block");
  }
  console.writeline("After finally");
  

これは何を印刷しますか？何もない！catchブロックがエラーを発生させたため、エラーがスローされます。

優れたプログラミング構造では、このコードが別のレイヤーから処理されるという意味で、例外が集中します。このような場合を刺激するために、このコードをネストしてみます。

try
{    
 try
    {
     int a=1;
     int b=0;
     int c=a/b;
    }
    catch(Exception ex)
    {
     throw(ex);
    }
    finally
    {
     console.writeline("Finally block")
    }
    console.writeline("After finally");
}
catch(Exception ex)
{
 console.writeline(ex.Message);
}

この場合、出力は次のようになります。

• 最後にブロックする
• ex.Message--それが何であれ。

例外をキャッチして他のレイヤーに再度スローすると（Funneling）、スロー後のコードが実行されないことは明らかです。これは、関数内の戻りが機能するのと同じように機能します。

これで、catchブロックの後にコードでリソースを閉じない理由がわかりました。finallyブロックに配置します。