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

BuriKaigi2025の登壇資料です。
https://fortee.jp/burikaigi-2025/proposal/99b15841-f9b6-40b6-805f-b66582ee3abd

Transcript

1. BuriKaigi 2025 例外処理を理解して、 設計段階からエラーを 見つけやすく、起こりにくく 梶川 琢馬 @kajitack
2. 梶川 琢馬 (Takuma Kajikawa) 2023年に中途入社、リアーキテクトやデザインシステムに取り組んでいます。 趣味はトライスロンやランニング。
 TechBowl社内でもランニングを報告するチャンネルがあります。 富山県高岡市出身ですが、BuriKaigiは初参加です！ 株式会社 TechBowl プロダクトエンジニア @kajitack
3. https://techtrain.dev/engineer-type-diagnosis #エンジニアタイプ診断 自己紹介に使ってみてください！
4. 9 例外処理を設計段階に組み込んだ背 9 例外処理を理解す 9 例外を分類す 69 設計に組み込Ç Æ9 例外を使わないパターンを考えてみる 今日話すこと webアプリケーションの想定。コード例はPHPですが、例外処理全般について話します。
5. U 例外処理の役割を理解できるようにす4 U エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの設計をチーム でディスカッションするためのヒントを得る 今日のゴール
6. 例外処理を設計に組み込んだ背景
7. →プロダクトの複雑化 例外処理を設計段階に組み込んだ背景
8. TechTrainについて 本気で、 エンジニアキャリアを伸ばす、 エンジニア塾。 “本気で実力をつけたい。”
9. 背景: プロダクトの複雑化 もともとはエンジニアメンターに メンタリング、技術相談ができるサービスとして開始。
10. 背景: プロダクトの複雑化 個人向けのサービスから、法人向けにも拡大 扱うドメイン知識が増えた
11. 複数のサービス、無数のクラスの ルールがある メンターとの面談機U 5 面談予約を作るときは引数は〇〇とXXが必6 5 面談予約をキャンセルする場合は開始前である必要 こういったルールを違反した場合に例外処理を行いたい。 ドメインモデル図 オブジェクトに対する制約 背景: プロダクトの複雑化
12. 例外処理を理解する
13. 1. エラーの発生を明示的に知らせて処理を中断する 2. 通常の制御フローとエラーハンドリングを分離する 3. エラー情報を詳細に保持し、デバッグを容易にする 例外の役割
14. エラーの発生を明示的に知らせて処理を中断する
15. https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント
16. throwすることで処理が中断される 例外を投げることによって処理を中断できる DBへの保存前にデータの整合性をチェックしている
17. 通常の制御フローとエラーハンドリングを分離する
18. 0 エラーチェックが増えてコードが読みにく$ 0 エラーメッセージの処理が分散していて、保守がしにく$ 0 異常が起きても単にメッセージを表示するだけ if 文でエラー処理を行う場合
19. G 異常が発生した場合は throw で即座に処理を中断し、呼び出し元に通 G エラーを区別できÉ G 呼び出し側に中断後の処理を任せることができる 例外を使って異常系を分離する
20. エラー情報を詳細に保持し、デバッグを容易にする
21. https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント
22. そのままクラッシュするわけにはいかない... 例外オブジェクトが持つ情報をもとにエラーの内容を伝える APIのレスポンスに変換 ログへの書き込みやアラート
23. 1. 通常の制御フローとエラーハンドリングを分離する if 文でエラーをチェックする代わりに、例外を用いることで正常系と異常系の処理を明確に分けることができる。 例: try-catch を使うことで、異常が発生した際の処理を一箇所にまとめられる。 2. エラーの発生を明示的に知らせる 例外をthrowする可能性があることをコードを通して、知らせる事ができる。 例えば、不正な入力 (InvalidArgumentException) や、リソースの取得失敗 (IOException) など。 3. エラー情報を詳細に保持し、デバッグを容易にする スタックトレースを提供し、エラー発生場所や原因を特定しやすくする。 例: RuntimeException("User not found") は、単なる return null よりも原因が明確。 例外の役割
24. 例外を分類する
25. ) 実装や技術的な問題で起きるエラ( 6) ユースケースで想定できる例外 エラーと例外というふうに分けてますが、例外処理では同じ扱い 例外の種類
26. 実装や技術的な問題で起きるエラー ユーザーが通常のユースケースとして回避できないエラー。HTTPステータスでいう500系 起きる原) & バD & DBや外部APIなどの接続エラ & データの不整合 ユースケースで想定できる例外 クライアント側の問題。HTTPステータスでいう400系 起きる原) & アプリケーション特有の制約違€ & (例) 予約する際の件数制限を超えていた
27. 誰の責務か？をハッキリさせる e ユーザーからの入力がおかしいと9 e クラスの処理の事前条件を満たせないと9 e ドメインロジックによって起きたと9 e DBや外部APIからデータ取得したとき
28. Presentation Infrastructure Application Domain Presentation Infra Application Domain 処理の流れ 例外の流れ 責務ごとにレイヤーを分けて考えていきます 依存の方向
29. Presentation Httpのステータスコードなど、プロトコルやUIに密接な情報を持つ例外 ユースケースの問題を表す例外(Presentationから見ると400系) DBの接続エラーやライブラリが投げる例外 「口座の残高不足」など、ドメインロジックの中で想定する例外 Infra Application Domain 各レイヤーで投げる例外 例外の流れ
30. 設計に組み込む
32. 62 入力値としてメールアドレスを受け取 2 仮登録状態にす 42 仮登録メール経由で、登録フローに遷移 新規登録の流れ
33. Presentation Infrastructure Application Domain Presentation Infra Application Domain 処理の流れ 例外の流れ 責務ごとにレイヤーを分けて考えていきます 依存の方向
34. F@ 入力値としてメールアドレスを受け取 "@ 仮登録メールアドレスValueObjectを作È B@ 仮登録Entityを作È #@ DBに保存 Presentation Infra Application Domain ドメインモデルを中心とした処理の流れ
35. 入力値としてメールアドレスを受け取る Presentation Application 入力値のバリデーションを行I H メールアドレスの形式がおかしb H 想定できる例外
36. ハンドリング(入力値のバリデーションエラー) 想定できる例外が投げられたのでハンドリング 投げられた例外は誰の責務？ →フロントエンドのバリデーションミスによるもの Presentationレイヤー(FW)で 例外をHTTP レスポンスに変換す„ P ステータスコード 422 で返% P 詳細なエラーメッセージを返す Presentation
37. メールアドレスValueObjectを作成 Application コンストラクタで形式をチェッb P 呼び出し側の実装ミス（Application層のバリデーション） →バグ Domain
38. ハンドリング（呼び出し側の実装ミス） 例外をHTTP レスポンスに変換す7 5 ステータスコード 500 で返8 5 「予期せぬエラーが発生しましたQ 5 エラーレポートする Presentation
39. 仮登録Entityを作成 Domain Entity作成前にメールアドレスが仮登録・本登録済みでないかを チェッX 4 もし登録済みだった場 4 想定できる例外
40. ハンドリング（登録済みだった） 投げられた例外は誰の責務？ →ユースケース違反 利用方法が違うことを表す例外を投げる 例外をHTTP レスポンスに変換すg f ステータスコード 422 で返i f 詳細なエラーメッセージを返す Presentation Application
41. DBに保存 Domain Infra DAOを通じてValueObjectの値を取り出して永続I ) DB接続エラR ) テーブル定義とのデータ型ミスマッチ →バグ
42. ハンドリング（DBへの永続化エラー） 例外をHTTP レスポンスに変換す7 5 ステータスコード 500 で返8 5 「予期せぬエラーが発生しましたQ 5 エラーレポートする Presentation
43. 一箇所にまとめるHandlerを作る (FWの機能を利用する) APIのレスポンスに変換 ログへの書き込みやアラート Presentation ハンドリング全般
44. 想定外の例外が投げられないことをデバッグする r 検証環境の段階でエラーレポートやログを確認でき8 r IDEで例外クラスを指定して、BreakPointが貼ってデバッグできる
45. 想定した例外を投げることをテストする x 戻り値のチェック等と同様に例外が投げられるかをテストす0 x 投げるべきところで投げてないなら他の箇所でエラーになる可能性が高い →テストしておくことで、他の箇所ではエラーが起きにくくなる
46. 想定できる例外はコンテキストごとに違う チームで議論しながら例外をモデリングする ドメインモデル図 オブジェクトに対する制約
47. ドメインモデル図 オブジェクトに対する制約 https://zenn.dev/techtrain_blog/articles/334ac36e79d946 モデル図の詳細はこちら
48. 3 責務によって例外を分け@ 3 想定外のエラーを「見つけやすい2 3 テストコードで想定する例外をテストすることで他の箇所では「起きにくい」 例外を設計に組み込むことによって...
49. 例外を使わないパターンを考えてみる
50. 例外処理の課題 m goto文のように流れが変わるので、どこでエラーが起こるか分かりづらƒ m try-catch で囲まれていないと、例外が上位の関数まで伝播してしまい、意図しない挙動を引 き起こすことがあ“ m 例外は関数に明示されないため、どの関数が例外をスローするかが不明確になりがv m throws宣言のようなチェックする機構もあるが、開発者によってまちまv m 何を例外とするかが曖昧になりがち
51. 想定できる例外って...？
52. 例外とは、何か例外的なもの（ある意味、あり得ない）を表現するもの であるとした場合、 失敗は想定できる結果であるため、その失敗を例外としてモデリングす ることは概念的におかしい。 そのため、処理失敗は成功したときと同じように扱う形で設計をしてモ デリングします。 例外というよりは失敗
53. Result<T, E>型 成功と失敗のどちらかを明示的に表現できる • 成功 (Ok(T)) → 正常な値 T を返す • 失敗 (Err(E)) → エラー情報 E を返す 戻り値として型が明示されるため、エラーが発生する可能性が一目で分かる 定義したResult型を利用 例外ではなく戻り値で結果を返す
54. 例外との混在はどうする？ Presentation Infrastructure Application Domain 依存の方向 ドメイン層でのみResult型を使用し、 Application層で例外を投げる StackTraceが課題...?
55. 現状は、Result型は取り入れてない y 例外クラスの設計をしっかりやv y 例外を関数のdocで宣言し、静的解析でチェックすv y 言語に組み込まれているなら積極的に使っても良さそH y 設計が重要なのは例外処理と同様
56. w チームの中で例外処理についての認識を合わせE w 設計でエラーを「見つけやすく」「おきにくく」しE w 例外機構を持たない言語では戻り値でエラーを表現す w 例外機構を持つ言語でもResult型を取り入れる検討の余地がありそう まとめ 皆さんのプロジェクトではどうしてるか？ぜひ聞かせてください！
57. ご清聴ありがとうございました！ TechTrainではメンターを募集中です！ 興味ある方はぜひ声かけてください！ ↑メンターの活動一部抜粋