try-with-resources の主なポイントは、情報を失うことなくリソースが確実に閉じられていることを確認することです。
try-with-resources を使用しない場合、例外マスキングと呼ばれる潜在的な落とし穴があります。try ブロックのコードが例外をスローし、finally の close メソッドも例外をスローすると、try ブロックによってスローされた例外が失われ、finally でスローされた例外が伝播されます。有用な例外は有益な例外であるのに対し、クローズ時にスローされる例外は役に立たないものであるため、これは通常不幸なことです。(そのため、どの参照整合性制約に違反したかを示す SQLException が表示される代わりに、リソースのクローズに失敗した BrokenPipeException のようなものが表示されます。)
この例外マスキングは、try-with-resources が発生を防止する厄介な問題です。
例外マスキングが重要な例外情報を失わないようにする一環として、try-with-resources が開発されたとき、close メソッドからスローされた例外をどうするかを決定する必要がありました。
try-with-resources では、try ブロックが例外をスローし、close メソッドも例外をスローした場合、close ブロックからの例外が元の例外に追加されます。
...兄弟コードブロック、特にtry-with-resourcesステートメントのtryブロックと、リソースを閉じるコンパイラ生成のfinallyブロックで、2つの独立した例外がスローされる状況があります。このような状況では、スローされた例外の 1 つだけを伝播できます。try-with-resources ステートメントでは、そのような例外が 2 つある場合、try ブロックから発生した例外が伝播され、finally ブロックからの例外が、try ブロックからの例外によって抑制された例外のリストに追加されます。例外がスタックをアンワインドすると、抑制された複数の例外が蓄積される可能性があります。
一方、コードが正常に完了しても、使用しているリソースが閉じるときに例外をスローする場合、その例外 (try ブロック内のコードが何かをスローした場合は抑制されます) がスローされます。つまり、ResultSet または PreparedStatement が try-with-resources によって閉じられる JDBC コードがある場合、JDBC オブジェクトが閉じられたときのインフラストラクチャの不具合に起因する例外がスローされ、そうでなければ正常に完了したはずの操作がロールバックされる可能性があります。 .
try-with-resources がない場合、close メソッドの例外がスローされるかどうかは、アプリケーション コードによって異なります。try ブロックが例外をスローしたときに finally ブロックでスローされた場合、finally ブロックからの例外は他の例外をマスクします。ただし、開発者には、クローズ時にスローされた例外をキャッチし、それを伝播しないオプションがあります。