例外を「隠す」な、型で飼い慣らせ：Hackにおける `` の深淵
Hack言語を単なる「型付きPHP」だと思っているなら、君のアーキテクチャはすでに脆弱だ。HHVMの型チェッカー（HackC）は、単にコードを走査しているのではない。コードベースの「状態遷移の整合性」を厳格に管理している。
多くの開発者が、例外処理を「適当な場所でtry-catchすればいいや」というお祈り駆動で実装している。だが、大規模なシステムにおいて、予期せぬ例外はシステムを崩壊させるトリガーだ。今回は、Hackの `<<__Throws>>` アノテーションを駆使し、呼び出し側に「例外をハンドリングする義務」を強制する、堅牢なAPI設計を伝授する。
—
なぜ `` が必要なのか？
PHPの世界では、関数が何を投げるかはドキュメントコメント（PHPDoc）に書かれるのが通例だ。だが、ドキュメントはコンパイル時に検証されない。コードがリファクタリングされ、例外が追加されても、呼び出し側のコードは一切気づかずに爆死する。
Hackの `<<__Throws>>` は、「この関数が投げる例外の型」を契約（Contract）として型システムに組み込む仕組みだ。これにより、呼び出し元は「確実に処理しなければならない例外」をコンパイル時に認識できる。
悪い設計：契約なき例外
// 呼び出し側は何が起きるか分からない。ランタイムで落ちるまで気づけない。
function withdraw(int $amount): void {
if ($amount > $this->balance) {
throw new InsufficientFundsException();
}
// …
}
—
堅牢な設計パターン：Exceptionの型階層化と制約
実務で使うべきは、例外を「型」として制御することだ。以下のパターンをそのままプロダクションに組み込んでほしい。
実践的なプロダクションコード例
namespace App\Banking;
// 1. 例外の型階層を作る
abstract class BankException extends \Exception {}
class InsufficientFundsException extends BankException {}
class AccountLockedException extends BankException {}
final class AccountService {
/
- <<__Throws>> を明示することで、呼び出し側にハンドリングを強制する
/
<<__Throws(InsufficientFundsException::class, AccountLockedException::class)>>
public function withdraw(int $amount): void {
if ($this->isLocked()) {
throw new AccountLockedException(“口座がロックされています”);
}
if ($amount > $this->balance) {
throw new InsufficientFundsException(“残高不足です”);
}
// … 決済処理
}
}
// 呼び出し側のコード
function processTransaction(AccountService $service): void {
try {
$service->withdraw(1000);
} catch (InsufficientFundsException $e) {
// 回復可能なエラーとしてハンドリング
renderError(“残高を確認してください”);
} catch (AccountLockedException $e) {
// セキュリティ上の警告を記録
Log::critical(“ロックされた口座へのアクセス”);
}
// ここで、もし別の例外（未知の例外）を投げたいなら、
// 呼び出し側の関数にも <<__Throws>> を伝搬させる必要がある。
}
—
アーキテクチャの急所：パフォーマンスと保守性
ここで、Hackのチーフアーキテクトとして一つ忠告しておく。`<<__Throws>>` を過剰に使うと、コードベースが「例外まみれ」になり、呼び出し側のシグネチャが肥大化する。
1. 例外を「制御フロー」に使うな
例外はあくまで「異常系」だ。バリデーションエラーのような「予測可能なビジネスロジックの結果」は、例外ではなく `Result
2. コンパイル時間のコスト
厳格な型チェックは、HHVMの型チェッカーに負荷をかける。しかし、実行時の `try-catch` によるオーバーヘッドよりも、型安全によるデバッグコスト削減の方が遥かに投資対効果が高い。「型チェックで時間を使い、実行時エラーをゼロにする」。これがプロフェッショナルの姿勢だ。
3. 未知の例外（Unchecked Exception）との境界
すべての例外をチェック対象にすべきではない。DB接続失敗や致命的なメモリー不足のような「アプリケーションがどう足掻いても回復できない例外」は、意図的にチェックを外す（`<<__Throws>>` に含めない）設計も必要だ。この「ハンドリングすべき例外」と「無視すべき致命的例外」の境界線こそが、アーキテクトの腕の見せ所となる。
—
結びに：君のコードを「予測可能」にせよ
`<<__Throws>>` は、ただの装飾ではない。それは君が書いたコードが「どのようなリスクを孕んでいるか」を後続のエンジニア、そしてコンパイラに伝えるための「宣誓書」だ。
この記述を徹底することで、君のチームのコードは「なぜか落ちる」という非決定的な恐怖から解放される。厳格な型システムは、君の自由を奪う鎖ではない。君のコードを、誰よりも速く、誰よりも堅牢にするための最強の武器だ。
さあ、今すぐ `<<__Throws>>` を導入し、君のAPIのインターフェースを「契約」によって武装させろ。バグはコードが走る前に、コンパイル時に葬り去るべきだ。