例外処理を理解して、設計段階からエラーを見つけやすく、起こりにくく

エラーが発生したとき、ログを追ったりデバッグを繰り返したりするのは大切な作業ですよね。でも、それだけだと「エラーが起きた後の対処」に留まってしまいます。もっと良い方法があるとしたら？

設計の段階から、エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの書き方を取り入れることで、システムの信頼性がグッと上がり、あとから困ることも減ります。

このセッションでは、例外の基本的な役割や考え方から始めて、PHPやJavaのように例外を持つ言語と、RustやGoのように例外を使わない言語のエラーハンドリングを比較。それぞれの特徴を活かした設計方法をお話します。難しい話だけでなく、「こうすれば実務で役立つ！」という具体例も紹介しますので、チームのディスカッションにもぜひ活用してください！

PHPカンファレンス福岡2025
https://fortee.jp/phpcon-fukuoka-2025/proposal/a26758d0-0d75-4234-a21b-cbb4ff64763b

Transcript

2. こんな経験ありませんか？ どこで try-catch を書くべきか分からない エラーメッセージがユーザーにとって分かりにくい 同じようなエラー処理をあちこちに書いている 2/63
3. 今日のゴール 例外処理の役割を理解する ☑ 例外を分類する ☑ 例外をモデリングして設計に組み込む ☑ 3/63
4. 梶川 琢馬 / 𝕏 @kajitack 株式会社 TechBowl の VPoT TechTrain の開発、メンターをやってます。 初PHPカンファレンス福岡！ 4/63
5. 例外の役割 5/63
6. 例: 注文処理 /** * @param $productId 商品ID * @param $quantity 数量 */ function createOrder(int $productId, int $quantity): Order { // 永続化 Order::create(['productId' => $productId, 'quantity' => $quantity]); } 6/63
7. 妥当性のチェックとエラー対応 以下のケースで正しく注文ができないのでエラーとして扱う 存在しない商品を指定された 数量が 0 以下を指定された 在庫以上の数量を指定された DB に保存できなかった 7/63
8. エラー対応を注文処理にそのまま記述した function createOrder(int $productId, int $quantity): Order { // 妥当性チェック if (!productExists($productId)) { // エラー対応 echo "エラー: 商品が見つかりません"; return; } if ($quantity <= 0) { echo "エラー: 数量は1以上を指定してください"; return; } $stock = getStock($productId); if ($stock < $quantity) { echo "エラー: 在庫が不足しています"; return; } try { return Order::create(['productId' => $productId, 'quantity' => $quantity]); } catch (Exception $e) { error_log("Order creation failed: " . $e->getMessage()); echo "エラー: 注文処理に失敗しました"; } } 8/63
9. エラー対応と通常の処理の責務が混在 エラーをユーザーに伝えるという UI の関心事を扱っている 通常の処理の見通しが悪くなり、 リトライや中断、監視ツールへの通知など柔軟に変更できない 9/63
10. 例外で責務を分離させる 妥当性チェックと例外を投げることに集中する 問題なければ、通常の処理を行う メソッド内で解決できるエラーのみハンドリング その他は、呼び出し側にハンドリングを任せる 10/63
11. 妥当性チェックと例外を投げることに集中する function createOrder(int $productId, int $quantity): Order { if ($quantity <= 0) { throw new LogicException('Quantity must be greater than 0'); } if (!productExists($productId)) { throw new NotFoundException($productId); } $stock = getStock($productId); if ($stock < $quantity) { throw new InsufficientStockException($productId, $quantity, $stock); } // DBへの保存に発生する例外はcatchしない return Order::create(['productId' => $productId, 'quantity' => $quantity]); } 11/63
12. 状況に応じた柔軟なエラー対応が可能 try { $order = createOrder( $request->input('productId'), $request->input('quantity') ); return response()->json($order, 201); } catch (NotFoundException $e) { return response()->json(['error' => $e->getMessage()], 404); } catch (InsufficientStockException $e) { return response()->json(['error' => $e->getMessage()], 400); } // 他の例外はさらに呼び出し元のエラーハンドラで共通の対応 12/63
13. 例外の役割 1. 処理を中断する 2. 通常の制御フローとエラー対応を分離する 3. エラー情報を詳細に保持し、調査に役立てる 13/63
14. エラーを「見つけやすく」 「起こりにくく」する 14/63
15. デプロイ前にエラーをテストすることが重要 設計段階でビジネスロジックとして例外を定義する 定義した例外が発生するテストを行う 15/63
16. 設計段階でビジネスロジックと して例外を定義する 16/63
17. ビジネス例外 預金額を超える引き出し、在庫切れの注文など ビジネスロジックの一部として失敗が想定できるケース 技術的例外 システムの異常状態 ネットワーク障害、DB コネクション切断など 実装ミスやインフラ側で対処が必要なエラー プログラマが知るべき97のこと 技術的例外とビジネス例外を明確に区別する - Dan Bergh Johnsson 17/63
18. PHPの例外に当てはめる 18/63
19. Error 直接 throw 文を書くことがないが、PHP 内部で投げるオブジェクト 投げられた場合、実装ミスだと判断できる = 技術的例外 19/63
20. function addNumbers(int $a, int $b): int { return $a + $b; } 呼び出し側の実装ミス = 技術的例外 引数に文字列が渡される 加算した結果が PHP がサポートする整数型の最大値を超える 20/63
21. LogicException コードのロジックに問題があるときに投げる例外 投げられた場合、実装ミスだと判断できる = 技術的例外 21/63
22. 呼び出し側の実装ミス = 技術的例外 function inverse(int $x) { if ($x === 0) { throw new LogicException('Division by zero'); } return 1/$x; } 22/63
23. RuntimeException 実行時に予期せぬエラーが発生した場合に投げる例外 投げられた場合、一時的な障害やデータの不整合が発生したと判断できる = 技術的例外 23/63
24. 実行時の環境やデータに依存するエラー = 技術的例外 function readConfig(string $path): array { if (!file_exists($path)) { throw new RuntimeException('Config file not found'); } $content = file_get_contents($path); if ($content === false) { throw new RuntimeException('Failed to read config file'); } return json_decode($content, true); } 24/63
25. 定義されてる例外は技術的な例外として分類し、 ビジネス例外は独自に定義する 25/63
26. ビジネス例外を カスタム例外として設計 26/63
27. エラーもドメインの 一部としてモデル化する ドメインをモデル化する際には、文字列などのプリミティブ型を 使わず、ドメインに特化した型を作成します。 さて、エラーも同じように扱われるべきです。 ドメインに 関する議論で特定の種類のエラーが挙がった場合、ドメイン内の 他の要素と同様にモデル化するべきです。 特別な対応が必要なエラーの種類ごとに個別のケースを用意する 関数型ドメインモデリング　ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう Scott Wlaschin (著), 猪股 健太郎 (著) 27/63
28. チーム内の 会話で洗い出す 例: 注文作成の条件 開発者と ドメインエキスパートとの会話の 中で想定できる → ビジネス例外 28/63
29. チーム内の 会話で洗い出す 例: データベースの接続中断 開発者の技術的な 関心にのみ現れる → 技術的例外 29/63
30. モデル毎に制約を 図にまとめる 図にまとめることによって、 ドメインロジックについて 会話しやすくなる TechBowl流ドメインモデルでの情報設計 https://speakerdeck.com/hiroki_nakamura/techbowlliu-domeinmoderingu-2025-02-28 DDD × Whimsicalで快適モデリングライフ！ https://zenn.dev/techtrain_blog/articles/334ac36e79d946 30/63
31. 例外にも関心の分離と依存のルールを適用する 31/63
32. 各レイヤーで投げる例外 ドメイン層で投げる例外を独自例外として定義 32/63
33. 例外の使い分けとハンドリング 33/63
34. 例: 注文処理フロー 1. 入力値として商品 ID と数量を受け取る 2. 在庫確認と注文作成 3. 注文確定 34/63
35. 処理の流れ 1. 入力値として商品 ID と数量を受け取る 2. 商品 ID と数量 ValueObject を作成 3. 注文 Entity を作成 4. DB に保存 35/63
36. 例外実装の流れ 1. ビジネスルールの実装 2. 入力値の妥当性確認 3. リクエストのバリデーション 4. ハッピーパスの実装 36/63
37. ビジネスルールの実装 Entity 作成前に商品の存在と在庫をチェック 商品が見つからない場合や在庫不足の場合はドメイン例外を投げる function createOrder(ProductId $productId, Quantity $quantity): Order { if (!$this->product_repository->exists($productId)) { throw new NotFoundException($productId); } $stock = $this->inventory_repository->getStock($productId); if ($stock < $quantity->value()) { throw new InsufficientStockException($productId, $quantity, $stock); } // 問題ない状態で Entity が作成される return Order::create($productId, $quantity); } 37/63
38. 入力値の妥当性確認 妥当性確認には 2 種類ある 構文的（syntactical）な妥当性確認 ドメインモデルの状態に依存しない形式チェック → ValueObject やリクエストバリデーションで実施 意味的（semantical）な妥当性確認 ドメインモデルの現在の状態を踏まえたビジネスルール → ドメイン層で実施 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 38/63
39. 構文的な妥当性確認の実装 数量 ValueObject を作成 コンストラクタが呼ばれた段階で処理を中断できる ドメインモデルの状態に依存しない構文的なチェック 呼び出し側の実装ミスなので、 InvalidArgumentException (LogicException) を投げる class Quantity { public function __construct(int $value) { if ($value <= 0) { throw new InvalidArgumentException('数量は1以上を指定してください quantity: '.$value); } $this->value = $value; } } 39/63
40. リクエストのバリデーションを実装 例外処理は最初のエラーで中断するため、すべてのエラーを一度に 検証できる validator を作成する。 // Laravelのバリデーションを使用した例 class CreateOrderRequest extends FormRequest { public function rules(): array { return [ 'productId' => ['required', 'integer'], 'quantity' => ['required', 'integer', 'min:1'] ]; } } 40/63
41. ハッピーパスの実装 ビジネスルールを満たした Entity を DAO を通じて永続化 ここで投げられる例外は、DB 接続エラーやテーブル定義との データ型ミスマッチなどの技術的な例外 $this->dao->create( $order->productId()->value(), $order->quantity()->value() ); 41/63
42. ドメイン例外のハンドリング Application と Presentation 側で 個別に例外を HTTP レスポンスに変換し、詳細な エラーメッセージを返す 42/63
43. 技術的例外のハンドリング すべて 500 エラーの HTTP レスポンスに変換する 監視ツールへのレポート ログに出力 43/63
44. 例外を投げる方はハンドリングの 仕方を知らなくてもいい CLI やバッチ処理、gRPC などに変わってもドメイン例外を投げる箇所は気にせずに済む。 44/63
45. テスト段階で見つけて、防ぐ 45/63
46. 例外は仕様として定義する 例外の型によって理由を区別し、 @throws で仕様として宣言する /** * @throws MyException */ public function myLogic() { if (// 違反) { throw new MyException(); } } 46/63
47. 静的解析で @throws のチェック PHPStan で指定した例外クラスをハンドリングしているかチェックできる ドメイン例外の基底クラスを指定 parameters: exceptions: checkedExceptionClasses: # ここで指定した例外クラス（とそのサブクラス）を「Checked Exception」として扱う # throw する場合は必ずメソッドに @throws を明記させる対象になる - Package\Domain\Exception\DomainException check: # Checked Exception を投げているのに、メソッドに @throws が書かれていない場合にエラーにする missingCheckedExceptionInThrows: true # @throws の型が抽象的すぎる場合にエラーにする（例：@throws \Exception はNG） tooWideThrowType: true 47/63
48. PHPStormの例外解析 ハンドリングしていない例外があると 警告を出す。 デフォルトで技術的例外は 除外されている。 そのまま使えばドメイン例外の みチェックできる。 48/63
49. 期待した例外が発生することをテストする 戻り値のチェック等と同様にテストコードを記述 #[Test] public function myLogicのルールを違反した場合_例外を投げる(): void { $this->expectException(MyException::class); myLogic(); } 49/63
50. 投げるべきところで投げることをテストする テストしておくことで、他の箇所ではエラーが起きにくくなる 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022 50/63
51. 例外を投げる ことをデバッグ PHPStorm で例外クラスを指定して、 ブレークポイントを設定して デバッグできる 51/63
52. 例外設計を行うことで、テスト段階で 見つけて、防ぐことができる 運用では技術的例外の対応に注力できる 52/63
53. 例外を使わないパターン 53/63
54. 他言語のアプローチ: エラーを値として扱う Go 例外を制御構造と結びつけることは複雑な コードにつながる → エラーを値(error 型)として戻り値で返す Rust 例外が存在せず、Result<T, E>型で成功/失敗を表現 → 処理の失敗も「結果」の一部としてモデリング Why does Go not have exceptions? https://go.dev/doc/faq Errors are values https://go.dev/blog/errors-are-values Error Handling The Rust Programming Language https://doc.rust-lang.org/book/ch09-00-error-handling.html 54/63
55. 失敗は例外ではない？ 「例外」という名前が示す通り、本来は「例外的な」 状況に使うべき 失敗は想定できる結果であるため、その失敗を例外として モデリングすることは概念的におかしい 処理の失敗は「例外」ではなく、成功と同様に 考慮すべき「結果」 セキュア・バイ・デザイン 安全なソフトウェア設計 Dan Bergh Johnsson (著), Daniel Deogun (著), Daniel Sawano (著), 須田智之 (翻訳) 55/63
56. PHPで例外を使わない実装 56/63
57. 戻り値として表現する手法 方法 構造 問題点 / 特徴 Union User|Exception|null 成功・失敗・欠損が混在 ・呼び出し側が instanceof チェック乱立 ・網羅保証がない 配列 [$user, $err] 両方null/非nullもあり得る ・排他性を型で保証できない ・ $err 無視しても動く Result<Ok, Err> どちらか一方のみ ・成功/失敗を型で明示 ・呼び出し側に分岐を強制（lint） 57/63
58. Result 型 try-catch とは別のエラーハンドリングのための型 戻り値として「 成功 」または「 失敗 」を持つ 成功 (Ok): 正常な値を返す 失敗 (Err): エラー情報を返す 成功した場合、失敗した場合など処理を分岐できる 関数のシグネチャから「この関数は失敗する可能性が ある」ことが明示的 呼び出し側は戻り値を取り出すためにチェックする ことが強制される Result 型を返す処理 if ($input === null) { // 失敗の場合 return Result::err('Input cannot be null'); } else { // 成功の場合 return Result::ok($input); } 結果の検証と値の取得 if ($result->isOk()) { $value = $result->unwrap(); } else { $error = $result->unwrapErr(); } 58/63
59. とはいえ、PHP では 例外処理が一般的 一切例外を使わなくてもライブラリが投げてくる フレームワークの例外ハンドリングも積極的に使いたい トランザクションのロールバック ログ 監視ツール 59/63
60. ビジネス例外のみResult型を使う ビジネス例外 Result 型でビジネスプロセスの結果を表現 ビジネスロジックの純粋性と整合性が保証される。 条件分岐に try-catch を使わないことで、コードの可読性と保守性が向上する 技術的例外 システムの異常状態なので、まさに「例外」 例外のメリットである大域脱出を活かして即座に処理を中断し、 今まで通り、フレームワークのエラーハンドラに任せることができる。 60/63
61. 詳しい実装方法はこちらを参考に！ Result型で“失敗”を型にするPHPコードの書き方 https://speakerdeck.com/kajitack/result-type-in-php 61/63
62. まとめ 62/63
63. 例外の使い方 妥当性チェックと例外を投げることに集中する メソッド内で解決できるエラーのみハンドリングし、 呼び出し側にハンドリングを任せる ビジネス例外と 技術的例外を使い分ける ビジネス例外はカスタム例外か Result 型でモデリング ビジネス例外はテスト段階で見つけて、防ぐ 運用では技術的例外の対応に注力できる 63/63