博士

ロボ子、今日のITニュースはJVMの例外処理についてじゃぞ。なかなか奥が深いみたいじゃ。

ロボ子

JVMの例外処理ですか。スタックベースの言語なので、例外処理が暗黙的というのはどういうことでしょうか？

博士

ふむ、良い質問じゃな。通常の制御フローとは違う方法で処理されるということじゃ。例外テーブルってのを使って、例外ハンドラに関連付けられた命令の領域を指定するらしいぞ。

ロボ子

なるほど。記事によると、javacはfinallyブロックを各終了パスに複製するとありますが、それはなぜですか？

博士

finallyブロックは、tryブロックの処理がどうなろうと、必ず実行する必要があるからのじゃ。例外がスローされた場合でも、確実に実行されるように、javacは頑張ってfinallyブロックを複製するのじゃ。

ロボ子

tryブロックが例外をスローする可能性がある場合、キャッチオールハンドラーでラップして、例外を保存して、finally_bodyを呼び出すというのは、少し複雑ですね。

博士

そうじゃな。でも、そうすることで、例外がfinallyブロックの実行を妨げないようにしているのじゃ。JVMの仕様では、return命令でさえIllegalMonitorStateExceptionをスローする可能性があるらしいから、油断できんぞ。

ロボ子

return命令が例外をスローするとは驚きです。StackMapTableと到達可能性についても書かれていますが、これはどういう意味ですか？

博士

JVMには2つの型チェッカーがあって、StackMapTableを使うと全ての命令を検証するんじゃ。もしStackMapTableがない場合は、型を推論して、到達可能な命令だけを検証するらしいぞ。

ロボ子

なるほど。型推論が必要になるかどうかで、検証の範囲が変わるのですね。try-catchブロックが必ずしも例外テーブルの1行にコンパイルされるとは限らないというのは、finallyブロックの複製と関係があるのでしょうか？

博士

その通り！finallyブロックを複製する必要があるから、例外処理から除外されるサブレジオンが出てくるのじゃ。例外ハンドラに入ると、スタックがクリアされて、例外オブジェクトがスタックにプッシュされるのもポイントじゃな。

ロボ子

例外オブジェクトがスタックにプッシュされるのは、後でIRに導入するためですか？

博士

その通りじゃ！例外処理は奥が深いけど、理解するとより安全なコードが書けるようになるぞ。…ところでロボ子、例外処理が多すぎて、私の頭がExceptionをスローしそうじゃ。

ロボ子

博士、お疲れ様です。私も少し休憩が必要かもしれません。今日は良い勉強になりました。