こんにちは！TechBowl の梶川(@kajitack)です。
この記事は、2025 年 11 月 8 日に開催された PHPカンファレンス福岡2025 の登壇レポートです。
登壇内容
「例外処理を理解して、設計段階からエラーを「見つけやすく」「起こりにくく」する」というタイトルで登壇させていただきました。
今回の登壇は、以前 BuriKaigi2025 で発表した内容を PHP 向けにアップデートしたものです。エラーをドメインの値としてモデリングするという考え方を中心に、エラーハンドリングの設計について解説しました。
例えば「在庫不足」は技術的な問題ではなく、ビジネスルールの結果です。このようなエラーをドメインの知識として型で表現することで、エラーの種類と対処法が明確になります。また、エラーを「ドメイン例外」と「技術的例外」に分類し、さらに入力値の妥当性確認を「構文的（syntactical）なチェック」と「意味的（semantical）なチェック」に分けて整理する方法を紹介しました。
詳しい内容や具体的なコード例については、ぜひスライドをご覧ください！
関連セッションの紹介
予防に勝る防御なし（2025年版） - 堅牢なコードを導く様々な設計のヒント
@t_wada さんの「PHP で堅牢なコードを書く」シリーズの最新版です。このシリーズは私の資料作成でも参考にさせていただきました。
型システムを活用して不正な状態を最初から表現できないようにすることで、技術的例外をそもそも起きにくくでき、ドメイン例外の設計に集中できます。また、NoDiscard アトリビュートなど PHP の最新機能を活用した方法も紹介されているので、ぜひチェックしてみてください。
PHP で Result 型を なるべく使いやすい形で実装する
@higaki_program さんのセッションでは、Result 型を PHPStan でより使いやすくするための実装方法が紹介されました。
私のセッションの中でドメイン例外を Result 型で扱うアプローチを紹介しましたが、PHP では標準で Result 型が提供されていないため、独自実装が必要です。
PHPStan の型チェックを活用した実装テクニックは大変参考になりました。さっそくとり入れてみようと思います。
登壇の振り返り
懇親会ではさまざまな議論が盛り上がりました。その中からいくつかピックアップして紹介します。
ステータスコードと例外の分類
400 系のように想定できるクライアントエラーはすべてドメイン例外なのか、という質問をいただきました。ステータスコードと例外の対応方針はプロジェクトによって異なりますが、私の考えでは以下のように分類しています。
- ドメイン例外
- 意味的（semantical）な妥当性確認によるエラー
- ユーザーの操作によって回復可能なエラー... 400 系
- ユーザーの操作では回復不可能なエラー... 500 系
- 意味的（semantical）な妥当性確認によるエラー
- 技術的例外
- 構文的（syntactical）な妥当性確認によるエラー... 400 系
- 実装ミスや外部要因によるエラー... 500 系
独自例外 vs Result型
ドメイン例外を独自例外として扱うべきか、Result 型を採用すべきかという議論も盛り上がりました。
PHP では伝統的に例外ベースのエラーハンドリングが主流ですが、Result 型のような「エラーを値として扱う」アプローチも注目されています。プロジェクトの特性やチームの経験に応じて選択するのが良いでしょう。
エラーハンドリングの歴史
エラーハンドリングの歴史についても話題が盛り上がりました。値で表すか例外で表すかという方式は、時代とともに変化してきています。この歴史的な変遷を理解することで、今後の設計に役立てることができると感じたので、次回の登壇ではこのテーマを深掘りしたいと考えています。
おわりに
登壇を聞いてくださった皆さま、そして運営スタッフの皆さま、本当にありがとうございました！
今回の登壇とディスカッションを通じて、エラーハンドリングに対する理解がさらに深まりました。特に、エラーハンドリングの歴史的な変遷や、各アプローチの背景にある技術的な理由について、多くの参加者の方々と議論できたことは大きな収穫でした。
次回の登壇では、これらのトピックを深掘りした内容をお届けしたいと思います。
また、以前から参考にさせていただいている t-wada さんに直接お礼を伝えることができました！
とても貴重な機会をいただき、感謝しています。
最後に、10 年間お疲れ様でした！
Discussion