ようこそ、Hackの世界へ。そして、プログラムの「深淵」へようこそ。
私はHHVM（HipHop Virtual Machine）のコア開発に携わってきたアーキテクトです。普段は型チェッカーの型推論アルゴリズムや、JIT（Just-In-Time）コンパイラが生成するx86_64マシン語の最適化に明け暮れています。
今日は、Hackを学び始めたばかりの君に、少しだけ「魔法の裏側」をお見せしましょう。テーマは「例外処理（Exception Handling）」です。
`try-catch`文は、エラーが起きた時にプログラムをクラッシュさせないための、非常に便利な道具ですね。でも、その一行がマシン語に翻訳されたとき、CPUの中で何が起きているか想像したことはありますか？
「例外は重い」という噂を聞いたことがあるかもしれません。なぜ重いのか、そしてHHVMはどうやってそれを処理しているのか。ここを理解すれば、君の書くコードの質は一段上のステージへと引き上げられますよ。
—
1. 「ハッピーパス」はタダである：Zero-Cost Exceptions
まず、素晴らしいニュースをお伝えしましょう。現代のHHVMにおいて、例外が発生しない限り、`try`ブロックを置くことによる実行速度の低下はほぼゼロです。
これを「Zero-Cost Exceptions」と呼びます。
function normal_flow(int $id): string {
try {
// ここが「ハッピーパス」（正常系）
// HHVMのJITは、tryがない場合とほぼ同じ速度のマシン語を生成します
return get_user_name_from_db($id);
} catch (Exception $e) {
return ‘Guest’;
}
}
昔のコンパイラは、`try`に入るたびに「エラーが起きたらここに戻ってきてね」という情報をメモリに書き込んでいました。しかし、HHVMのJITは賢いです。JITは「例外が起きる場所」のリストを、プログラムの実行コードとは別の場所（サイドテーブル）にこっそり作成します。
そのため、何事も起きなければ、CPUは`try`の存在を無視して猛スピードで駆け抜けることができるのです。
—
2. 「悲劇」は throw から始まる：スタックアンワインディング
ところが、一度 `throw` が呼ばれると、物語は一変します。平和な村（関数）に突然の災害が起き、救助隊（HHVMのランタイム）が出動するような騒ぎになります。
ここで発生するのが「スタックアンワインディング（Stack Unwinding）」です。
図解イメージ：スタックの逆送
1. throw発生！: 「誰かこのエラーを受け取ってくれ！」
2. 現在の関数をチェック: 「この関数内に`catch`はあるか？」 → なければ、この関数を破棄して呼び出し元へ。
3. 呼び出し元をチェック: 「ここにはあるか？」 → なければ次へ。
4. 見つかるまでループ: これをスタックの底まで繰り返します。
この「捜索活動」が非常に高コストなのです。HHVMは、JITが生成した複雑なマシン語の塊の中から、「今の実行地点（命令ポインタ）に対応する`catch`ブロックはどこか？」を巨大な表から引き直さなければなりません。
—
3. JITコンパイラが頭を抱える「レジスタの消失」
ここからが少しマニアックで、面白いところです。
CPUには「レジスタ」という超高速な小物入れがあります。JITコンパイラは、変数をこのレジスタに詰め込んで計算を最適化します。しかし、例外が発生すると、この「どのレジスタに何の変数が入っているか」という状態がすべて台無しになる可能性があるのです。
function heavy_optimization(): void {
$x = 10; // レジスタAに保存
$y = 20; // レジスタBに保存
try {
do_something(); // ここで例外が投げられるかも？
echo $x + $y;
} catch (Exception $e) {
// catchの中では、$x や $y が正しく復元されていなければならない！
}
}
JITコンパイラは、`catch`ブロックの中でも変数が正しく使えるように、例外が発生する可能性がある場所（関数の呼び出しなど）で、レジスタの内容を一度メモリに書き戻したり、特別な「復元用マップ」を作成したりします。
これをやりすぎると、せっかくのJITの最適化が阻害されてしまいます。「例外が起きるかもしれない」というだけで、JITは少しだけ慎重（保守的）なコードを書かざるを得なくなるのです。
—
4. 陥りやすい罠：制御フローに例外を使わない
初心者の開発者がやってしまいがちなのが、「正常な条件分岐」に例外を使ってしまうことです。
// ❌ 避けるべき書き方：ユーザーがいないことは「例外」ではない
try {
$user = find_user_by_email($email);
} catch (UserNotFoundException $e) {
$user = create_new_user($email);
}
// ✅ 望ましい書き方：nullを返すか、Result型のようなパターンを使う
$user = find_user_by_email($email);
if ($user === null) {
$user = create_new_user($email);
}
なぜ後者が良いのか？ それは、HHVMのJITにとって `if` 文は「予測可能な直線の道路」なのに対し、`try-catch` は「いつ爆発するか分からない地雷原」だからです。
`if` 文による分岐は、CPUの「分岐予測」という機能によってほぼゼロコストで処理されます。しかし、例外による制御フローは、前述した「スタックアンワインディング」を引き起こし、パフォーマンスを数十倍〜数百倍悪化させる可能性があります。
—
5. 先輩からのアドバイス：例外を「正しく」愛するために
Hackという言語は、型システムによって「何が返ってくるか」を厳格に管理できる素晴らしい言語です。だからこそ、以下のルールを心に刻んでおいてください。
1. 例外は「本当に異常な事態」だけのために使う。
- DBの接続が切れた、必要なファイルが存在しない、など。
2. 期待される結果がない場合は `?T` (nullable) を活用する。
- 「ユーザーが見つからない」のは、ビジネスロジック上の「正常な結果の一つ」です。
3. catchの中はシンプルに。
- catchブロックを巨大にすると、JITの最適化範囲（リージョン）が細切れになり、マシン語の効率が落ちます。
まとめ
HHVMのJITは、君が書いた `try-catch` を「実行時はタダだが、発生時は全力で救助する」という極めて合理的なマシン語に変換しています。
この構造を知っていれば、「ここは例外で飛ばすべきか、それとも `null` を返すべきか」という設計判断に迷ったとき、自信を持って答えを出せるはずです。
Hackの静的型システムとHHVMのパワーを最大限に引き出すのは、他ならぬ君の設計思想です。この調子で、Hackの深淵を楽しんでください。次は「ジェネリクスの型消去とJITの特殊化」の話でもしましょうか。
基本をマスターすれば、Hackは君の最強の武器になりますよ。応援しています！