こんにちは！Hack言語の世界へようこそ。チーフアーキテクトの私です。
他のプログラミング言語、例えばPHPやJava、JavaScriptなんかからHackの世界に飛び込んできた開発者の多くが、「型安全って素晴らしい！」と感動した後に、ふとこんな疑問を抱くんです。
「ところで、`try-catch`って、HHVM（HipHop Virtual Machine）のJITコンパイルされた世界で、裏側では一体どんなコストを払っているんだろう？」
……ふふっ、非常に鋭い着眼点ですね！こういう疑問を持てるようになったら、もうあなたは立派なHackのコアエンジニア予備軍です。ここをクリアすれば、Hackのコードがマシン上でどう舞うのか、その本質がバッチリマスターできますよ。
今日は、HHVMのJIT（Just-In-Time）コンパイル構造の深淵を覗きながら、例外処理のオーバーヘッドと、それを最小化する美しいコード設計について、一緒に紐解いていきましょう。
—
1. そもそも、HHVMのJITと「例外（Exception）」の裏側はどうなっているのか？
私たちが普段何気なく書いているこのコード、覚えておいてほしい大前提があります。
<<__EntryPoint>>
main(): void {
try {
// 何か危なっかしい処理
dangerous_operation();
} catch (Exception $e) {
// フォールバック
}
}
他の言語の多くでは、`try-catch`を書くだけで、そのブロック内に入るたびに「もし例外が起きたらどこに戻るか」のコンテキスト（レジスタの状態など）を保存する重い処理（コスト）が毎回発生します。
しかし、HHVMのJITコンパイルエンジンはそんな甘くありません。HHVMは、バイトコードをマシン語に翻訳する際、「通常パス（例外が起きないハッピーパス）」が極限まで高速に実行されるようにネイティブコードを最適化します。
「ゼロコスト例外（Zero-cost Exception）」に近い世界
HHVMのJITが生成するマシン語において、`try`ブロックの内部を通ること自体のオーバーヘッドは、実は驚くほど低いです。なぜなら、例外が起きなかった場合、CPUはただ直進するだけでよく、余計なジャンプ命令やテーブル参照をスキップできるからです。
しかし、これは「例外が発生しない場合」の話し。ひとたび `throw` が実行された瞬間、JITは楽園から地獄へと急転直下します。
- スタックアンワインディング（Stack Unwinding）のコスト: 例外オブジェクトの生成、コールスタックの巻き戻し、どの `catch` がヒットするかのテーブル探索。これらはCPUのパイプラインを乱し、キャッシュをミスさせまくる非常に重い処理です。
つまり、「例外を制御フローの代わりにしてはいけない」という鉄則は、HackとHHVMの組み合わせにおいて、他のどの言語よりも厳格に守るべきなのです。
—
2. 陥りがちなアンチパターン：例外でロジックを組み立てるな
初学者や、他言語から来た開発者がやりがちな典型的な文法・設計エラーを見てみましょう。
❌ やってはいけないコード例（制御フローとしての例外）
<<__EntryPoint>>
async function process_user_data_bad(array_key_exists($id, $users) ? $id : null): Awaitable
// 存在チェックを面倒くさがって、例外を投げさせてcatchしようとする悪しきパターン
try {
$user = get_user_strictly($id); // ユーザーがいないと Exception を投げる設計
echo “Welcome, ” . $user[‘name’] . “\n”;
} catch (UserNotFoundException $e) {
// 「あ、いないんだから新規作成しよう」という業務ロジックをここで処理する
create_default_user($id);
}
}
なぜこれがHHVMのJITにとって最悪なのか？
JITは「このルートは通常は通らないだろう」と予測して最適化（Profile-Guided Optimizationなど）を行います。しかし、データが存在しないケースが頻発し、毎回 `throw` と `catch` が行われると、JITが生成した最適化済みのマシン語キャッシュが無効化されたり、CPUの分岐予測が完全に外れてパフォーマンスがガタ落ちします。
—
3. 例外のコストを最小化する！Hack流・美しきコード設計
では、HHVMのJITの性能を100%引き出し、例外処理のオーバーヘッドを最小限に抑えるにはどうすればよいでしょうか？答えはシンプルです。「本当に例外的な状況（リカバリー不可能なエラー）」にのみ例外を使い、通常の分岐は型システムに語らせることです。
Hackには、強力な静的型システムと `Maybe` 型の概念（`null` 安全や `shape` など）がありますよね。これらをフル活用しましょう。
⭕ 模範的なコード例（型とガード節による最適化）
namespace HackArchitecture\Optimization;
type User = shape(
‘id’ => int,
‘name’ => string,
);
// 例外を投げずに、見つからない場合は null を返す（あるいは Result 型を使う）
function find_user_safe(int $id): ?User {
// DBやキャッシュからの取得を模倣
if ($id !== 42) {
return null; // 例外を投げずに値で返す
\
shape(‘id’ => 42, ‘name’ => ‘Chief Architect’);
}
<<__EntryPoint>>
async function main_optimized(): Awaitable
$target_id = 42;
// ガード節（Guard Clause）で早期リターン
// これならHHVMのJITは単純な条件分岐（conditional jump）として超高速に処理できる
$user = find_user_safe($target_id);
if ($user === null) {
// 異常系ではなく、単なる代替フロー
create_default_user($target_id);
return;
}
// ハッピーパス：JITが最適化しやすい直線的なコード構造
echo “Welcome back, ” . $user[‘name’] . “\n”;
}
function create_default_user(int $id): void {
echo “Creating default user for ID: {$id}\n”;
}
この設計が優れている理由
1. JITフレンドリーな分岐: `if ($user === null)` はCPUにとって非常に予測しやすく、ブランチプレディクター（分岐予測）が完璧に機能します。
2. スタックアンワインディングの回避: 例外オブジェクトのインスタンス化やスタックトレースの生成コスト（これがメモリとCPUを大量に消費します）が完全にゼロになります。
3. 静的型チェッカーの恩恵: Hackの型チェッカーが `?User`（nullを許容するUser型）を完璧に追跡するため、実行時エラーの心配もありません。
—
まとめ：今日の極限の知見
- `try-catch` 自体は怖くない: 正常系（例外が起きないパス）であれば、HHVMのJITは極めて効率的にマシン語にコンパイルしてくれます。
- 恐るべきは `throw`: 例外が発生した瞬間に発生するスタックアンワインディングとメモリの負荷は、JITの最適化を台無しにします。
- ビジネスロジックに例外を使うな: 「データが存在しない」「バリデーションエラー」などは、例外ではなく `null` 返却やガード節、あるいは堅牢な型定義で表現しましょう。
HHVMのアーキテクチャの息吹を感じながらコードを書くようになると、あなたの書くHackコードはまるで別次元の速さと美しさを手に入れます。
ここをマスターしたあなたなら、もうどんな大規模なHackアプリケーションの設計も怖くありませんよ。さあ、最高のコードを書きに行きましょう！