やあ。Hackの世界へようこそ。
HHVMの深淵からやってきたチーフアーキテクトだ。君が今、Hackの「厳格さ」という最強の武器を手に入れようとしていること、心から歓迎するよ。
多くの言語では「例外（Exception）」は突然のゲリラ豪雨のようなものだ。どこから降ってくるか分からず、備えを忘れるとシステムはあっけなくダウンする。だが、Hackの`<<__EntryPoint>>`や`strict`モードの世界では、私たちは「予見可能性」を何よりも愛する。
今回は、Hackにおける例外処理の型定義、`throws`アノテーションの設計について深掘りしていこう。ここを掌握すれば、君の書くコードは驚くほど堅牢になる。
—
なぜ「例外」を型で縛る必要があるのか？
一般的な言語では、関数が何を投げるかは「ドキュメント（コメント）」に頼るしかない。しかし、コメントは嘘をつくし、更新もされない。
Hackの`throws`アノテーションは、コンパイラが「この関数を呼ぶなら、この例外をハンドリングしなさい」と強制するための契約書だ。これを理解することは、コードの「血流」を理解することに他ならない。
1. `throws`アノテーションの基本
まず、最もシンプルな形を見てみよう。
<<__EntryPoint>>
function main(): void {
try {
echo get_user_name(1);
} catch (InvalidUserIdException $e) {
echo “エラー: ” . $e->getMessage();
}
}
// <<__EntryPoint>>を支えるこの関数は、特定の例外を投げることを宣言する
function get_user_name(int $id): string
throws InvalidUserIdException {
if ($id <= 0) {
throw new InvalidUserIdException("IDは正の整数である必要があります");
}
return "Hack Master";
}
class InvalidUserIdException extends Exception {}
このコードのポイントは、`throws`があることで、呼び出し元（`main`関数）が「あ、この関数は例外を投げる可能性があるんだな」と瞬時に察知できる点だ。型チェッカーが、この例外を握りつぶしていないか監視してくれる。これがHackの厳格さ（Strictness）の真髄だよ。
---
陥りやすい「罠」：チェック漏れと伝播
開発の現場でよく見るミスは、「例外を投げているのに、アノテーションを忘れる」こと。あるいは、「上位の関数でハンドリングせずに放置する」ことだ。
悪い例：沈黙するエラー
function process_data(): void {
// throwsが書かれていないのに例外を投げている
// これだと、呼び出し元は何が起きるか知る由もない
throw new RuntimeException(“予期せぬ障害”);
}
このコードは、型チェッカーが「君、隠し事をしていないか？」と問いかけてくれる場所だ。特に注意してほしいのは、「例外は関数のシグネチャの一部である」という考え方だよ。
—
設計の極意：例外は「インターフェース」として定義せよ
現場でプロフェッショナルな設計をするなら、例外をただ投げるのではなく、「例外のグループ」を定義するのが賢いやり方だ。
// 業務ドメインごとの例外基底クラスを作る
abstract class DomainException extends Exception {}
class DatabaseException extends DomainException {}
class ValidationException extends DomainException {}
// 関数は「ドメイン例外」を投げることを明示する
function fetch_data(): string
throws DomainException {
// 内部でDatabaseExceptionなどが投げられても、
// 呼び出し元はDomainExceptionで捕捉できる
throw new DatabaseException(“DB接続失敗”);
}
この手法を使えば、呼び出し元は詳細なエラーの種類を細かく追う必要がない。必要な抽象度で例外をキャッチできる。これが大規模開発における「例外の管理コスト」を下げる鍵になるんだ。
—
チーフアーキテクトからのアドバイス：例外と向き合う心構え
ここまで読んでくれた君に、一つだけ大事なことを伝えるね。
1. 「回復できるエラー」だけを例外にする:
`throws`で型定義すべきは、呼び出し元がハンドリングして回復できるエラーだけだ。致命的なバグ（Null参照や範囲外アクセスなど）は、例外でハンドリングするのではなく、型システムそのもので排除すべきだよ。
2. 型推論を信じすぎない:
Hackは賢いけれど、例外のフローは複雑だ。あえて明示的に`throws`を書くことは、君のコードを読む「未来の君自身」や「チームメイト」への最高のラブレターになる。
—
まとめ：ここをクリアすれば、君はもうHackの住人だ
- `throws`は契約: 関数が何を投げるかを明確にすることで、型チェッカーが君のガードマンになってくれる。
- 例外の階層化: 基底例外クラスを使って、呼び出し側のハンドリングをスマートにする。
- 型で語る: 投げられないエラーは型で防ぎ、投げうるエラーは`throws`で宣言する。
Hackの静的型システムは、君を縛るための鎖じゃない。君のコードを高速かつ安全に、HHVMの上で軽快に走らせるための「滑走路」なんだ。
さあ、エディタに戻って、君のコードに魂を込めた`throws`を書いてみてくれ。何か詰まったら、いつでも戻っておいで。Hackの世界で待っているよ。