末尾呼び出しの最適化に関する質問への回答に対するユーザーsocによるコメントでは、「ARM の追加」(ARM CPU のサポート?) により、Java 7 には「抑制された例外」と呼ばれる新しい機能があると述べられています。
このコンテキストでの「抑制された例外」とは何ですか? 他のコンテキストでは、「抑制された例外」は、キャッチされてから無視された例外になります (めったに良い考えではありません)。これは明らかに違うものです。
末尾呼び出しの最適化に関する質問への回答に対するユーザーsocによるコメントでは、「ARM の追加」(ARM CPU のサポート?) により、Java 7 には「抑制された例外」と呼ばれる新しい機能があると述べられています。
このコンテキストでの「抑制された例外」とは何ですか? 他のコンテキストでは、「抑制された例外」は、キャッチされてから無視された例外になります (めったに良い考えではありません)。これは明らかに違うものです。
Jonの回答の引用を明確にするために、メソッドによってスローできる例外は1つだけです(実行ごと)が、の場合、try-with-resources
複数の例外がスローされる可能性があります。たとえば、1つはブロックにスローされ、もう1つは。finally
によって提供される暗黙的にスローされる場合がありtry-with-resources
ます。
コンパイラは、これらのうちどれを「実際に」スローするかを決定する必要があります。try
暗黙のコード(ブロック)によってスローされる例外ではなく、明示的なコード(ブロック内のコード)で発生する例外をスローすることを選択しますfinally
。したがって、暗黙のブロックでスローされた例外は抑制されます(無視されます)。これは、複数の例外の場合にのみ発生します。
コメンターが参照しているのは、ブロックからスローされている既存の例外のコンテキストで、try-with-resourcesfinally
ブロックの暗黙的なブロック内でスローされたときに半無視される例外であると思います。try
try-with-resources ステートメントに関連付けられたコードのブロックから例外がスローされる可能性があります。writeToFileZipFileContents の例では、try ブロックから例外がスローされる可能性があり、ZipFile および BufferedWriter オブジェクトを閉じようとするときに、try-with-resources ステートメントから最大 2 つの例外がスローされる可能性があります。try ブロックから例外がスローされ、try-with-resources ステートメントから 1 つ以上の例外がスローされた場合、try-with-resources ステートメントからスローされた例外は抑制され、ブロックによってスローされた例外はwriteToFileZipFileContents メソッドによってスローされます。これらの抑制された例外を取得するには、try ブロックによってスローされた例外から Throwable.getSuppressed メソッドを呼び出します。
(これは、リンクされたページから「抑制された例外」というセクションを引用しています。)
抑制された例外は、リソースが閉じられたときにtry-with-resources ステートメント ( Java 7 で導入) 内で発生する追加の例外です。リソースのAutoCloseable
クローズ中に複数の例外が発生する可能性があるため、追加の例外は抑制された例外としてプライマリ例外に添付されます。AutoCloseable
try-with-resources サンプル コードのバイトコードを見ると、try-with-resources セマンティクスに対応するために標準のJVM 例外ハンドラが使用されています。
これは「連鎖例外機能」に関係していると思います。スタック トレースが進化するにつれて、この機能によって例外がどのように処理されるかに影響します。チェーンされた例外のグループの一部である時間の経過とともに、例外を抑制することができます。詳細については、Throwable のドキュメントを参照してください。