Tryを使用するための理由とシナリオは、キャッチを使用しないようにしません
JDK Concurrency Toolkitでは、多くの例外処理では、AbstractExecutorserviceなどの次の構造を使用しています。つまり、試してみるだけでキャッチはありません。
クラスX {Private resentrantlock = new ReentrantLock（）; Unlock（）}}}なぜこの構造を使用するのですか？利点は何ですか？最初に次のコードを見てください
public void ttryandfinally（string name）{try {name.length（）; // nullpointerexception} fullly {system.out.println（ "aa"）};nullを渡すことの実行結果は次のとおりです。コンソールにAAを印刷し、nullpointerexceptionを投げます。実行プロセスは、最初にTryブロックを実行し、例外が発生した後に最終的なブロックを実行し、最終的にTryに例外をスローすることです。この実行結果は非常に正常です。Catch例外ハンドラーは、すべてのメソッドが最終的に外側にスローすることができます。
このアプローチの利点は何ですか？ Trattryandfineの場合、それはしなければならないことを行い、呼び出し元の場合は例外をスローします。言い換えれば、この構造は責任の分離を実現し、例外処理と例外クリーニングの分離を実現し、さまざまな方法が彼らがすべきことに集中できるようにします。では、いつ財政的にTryを使用し、いつTry-Catch-Finallyを使用するのですか？明らかに、メソッド自体がTRYに表示される例外を処理できるかどうかに依存します。自分で処理できる場合は、メソッドの発信者に投げることなく直接キャッチします。 。つまり、スローがメソッドの署名に表示され、単独で処理することはできない例外を宣言しますが、メソッド内ですべきことを行います。
最終的な声明が実行されない状況
Javaの声明が実行されない唯一の状況は、プログラムの終了に使用されるSystem.Exit（）メソッドが最初に実行されることです。
public class test {public static void（string [] args）{system.out.println（ "start"）; } system.out.println（ "end"）;出力の結果は次のとおりです。
始める
もちろん、system.exit（）ステートメントなしで一般的なtryステートメントを実行したときにパワーが突然遮断された場合、すべてのプロセスが終了し、最終的にステートメントは実行されません。