エラーを定義から消し去る

エラーを定義から消し去る A Philosophy of Software Design 第10章から 1 / 24

目次例外はなぜ複雑さを生むのか例外処理コードの本質的な難しさと不必要な例外の増殖技法１：エラーを定義から消し去る APIの意味・定義を変更して例外条件そのものを排除する技法２：例外のマスキング低レベルで例外を処理し、上位レベルに見せない技法３：例外の集約多くの例外を一箇所でまとめて処理する技法４：クラッシュさせるだけ
回復が困難で頻度の低いエラーはアプリケーションを中止する 2 / 24

例外はなぜ複雑さを生むのか例外処理コードの本質的な難しさと不必要な例外の増殖 3 / 24

例外処理コードの本質的な難しさ例外処理が難しい理由テストの困難さ通常のコードの流れを中断する例外が発生した時に処理を続行するか、中止するか、どちらにしても複雑中止する場合、部分的に変更された状態を巻き戻す必要がある例外処理コード自体がさらなる二次的な例外を生む
I/Oエラーなど一部の例外はテスト環境で再現しにくい例外処理コードが実行される頻度は非常に低いバグが長期間検出されないまま残る 4 / 24

例外処理の冗長さ：Javaの例実際の例外処理を考慮しなくても、try-catchのボイラープレートだけで通常の操作コードより行数が多い本質的な処理はわずか3行。残りはすべて例外処理のための定型コード 5 / 24

例外が多すぎる不必要な例外の増殖「検出するエラーが多いほど良い」  → 過剰に防御的なスタイルきれいに処理する方法を見つける代わりに、例外をスローして問題を呼び出し元に丸投げ呼び出し元も何をすべきかわからない可能性が高い著者自身の失敗：Tclのunsetコマンド
unset（変数の削除）で、変数が存在しない場合にエラーをスロー → クリーンアップで存在しない変数も削除したいケースが頻発 → 開発者はcatch文で囲んでエラーを無視するコードを書く羽目に例外はインターフェースの一部。不必要な例外はクラスを浅くする 6 / 24

例外の複雑さを減らすには例外処理による複雑さの損害を減らす最善の方法は例外を処理しなければならない箇所の数を減らすこと 7 / 24

技法1：エラーを定義から消し去る処理すべき例外がないようにAPIを定義する 8 / 24

エラーを定義から消し去る例外処理の複雑さを排除する最善の方法は、処理すべき例外がないようにAPIを定義すること変更前：unset = 変数を削除する xが存在しない → エラー！変数が存在しない場合、仕事を遂行できない
例外を生成する「意味がある」ように見える変更後：unset = 変数が存在しないことを保証する xが存在しない → 作業は完了済み。OK 存在しない変数でunsetを呼ぶのは問題ない報告すべきエラーケースが存在しない操作のセマンティクス（意味・定義）をわずかに変更するだけで例外条件を消し去ることができる 9 / 24

例：WindowsとUnixのファイル削除 Windows：使用中のファイルは削除不可プロセスが開いているファイルは削除できない → ユーザーがプロセスを探して強制終了 → 最悪の場合、システムを再起動
Unix：削除を遅延させてエラーを消すファイルが開かれている状態で削除 → ファイルに削除マークを付け、削除操作は成功を返す → 既存プロセスは引き続き読み書き可能 → すべてのプロセスがファイルを閉じたらデータを解放 Unixは2種類の例外を定義から消し去った「削除操作のエラー」と「使用中ファイルの削除による既存プロセスへの例外」 10 / 24

例：Javaのsubstringメソッド現在のAPI 改善案範囲外のインデックスに対処するために、呼び出し元で5〜10行のチェックコードが必要インデックスが負でも、beginIndex > endIndexでも動作が明確に定義される
Pythonのリストスライスは実際にこのアプローチバグを減らす最善の方法はソフトウェアをシンプルにすること 11 / 24

リストAPIと404エラーあるAPIの設計で起きたこと実際の実装要素が0件 → 404 Not Found を返すフロント側で404をキャッチして空リスト
表示に変換するコードが必要にあるべき設計要素が0件 → 200 OK + `[]` を返すフロント側は配列の長さだけ見ればよいエラー処理が不要に「該当データがない」はエラーではなく空集合という正当な結果数学的にも自然な定義 12 / 24

技法2：例外のマスキング例外的な条件を低いレベルで処理し、上位に見せない 13 / 24

例外のマスキング例外的な条件をシステムの低いレベルで検出・処理し、上位レベルに見せない TCPのパケットロス処理パケットがドロップ TCP層が検出・再送クライアントはドロップを認識しないクライアントはパケットロスを意識する  必要がない NFSのサーバー障害処理 NFSサーバーがダウン
クライアントがリクエストを再発行サーバー復帰後にシームレスに再開アプリケーションはエラー処理コードが一切不要マスキングはインターフェースを縮小し、機能を追加する → より深いクラスをもたらす 14 / 24

キュー処理とマスキング AIサービスでのファイル処理フローシステム側の責任処理の流れユーザーがファイルをアップロードキューにジョブをディスパッチ 202 Accepted を返すここでユーザーの手を離れる
システム側で処理を完遂 API呼び出し失敗 → リトライ一時的な障害 → 待って再実行ユーザーには処理完了だけを通知やってはいけないこと「APIエラーが発生しました」をユーザーに返す → ユーザーにはどうしようもできない TCPがパケットロスをマスキングするようにキューワーカーが一時的なエラーをマスキングする 15 / 24

技法3：例外の集約多くの例外を1箇所でまとめて処理する 16 / 24

Webサーバーの例悪い例：個別にキャッチ良い例：最上位で集約大量のハンドラがすべて同じことを行うパラメータ欠落、構文エラー、権限不足…  すべて単一のハンドラで処理可能エラーメッセージはスロー側で生成新しい機能が追加されても同じ方法で例外をスローすれば既存のシステムに組み込める 17
/ 24

入口での集約（Zod + OpenAPI）スキーマ定義でバリデーションを一元化スキーマなし：  各ハンドラ内で`if (!id) return 400`のような個別チェックが散在
スキーマあり：バリデーションはスキーマ定義に一元化ハンドラはビジネスロジックに集中 18 / 24

フロントエンドでの集約（ErrorBoundary） TanStack Query + ErrorBoundary 個別にエラーハンドリング ErrorBoundaryで集約各コンポーネントはデータ取得に集中エラー表示は1箇所で統一バックエンドのonError、フロントエンドのErrorBoundary
レイヤーを問わず集約の原則は同じ 19 / 24 各コンポーネントでエラー表示コードが散在

技法4：クラッシュさせるだけ回復が困難で頻度の低いエラーはアプリケーションを中止する 20 / 24

クラッシュさせるだけ処理しようとする価値のない例外には、診断情報を出力してアプリケーションを中止するメモリ不足エラーの例クラッシュが適切なケースメモリ不足開いているファイルのI/Oエラー内部の不整合データ構造の検出ネットワークソケットが開けないメモリが枯渇したらアプリケーションにできることはほぼない
チェック漏れでnullポインタ参照するより明確にクラッシュさせた方がよいクラッシュが不適切なケースユーザー入力のバリデーションエラー回復がシステムの価値の一部である場合 21 / 24

集約 × クラッシュの合わせ技 HonoのonErrorハンドラ集約の側面あらゆる想定外エラーを1箇所でキャッチ → 各ハンドラに個別のtry-catchが不要クラッシュの側面回復を試みずそのリクエストを諦める 
→ 500を返して終了「どこで処理するか」は集約、「どう処理するか」はクラッシュ技法は組み合わせて使える 22 / 24

やりすぎに注意学生チームの失敗ネットワーク通信モジュールですべての  ネットワーク例外をマスキングエラーが発生しても、キャッチして破棄し  何事もないかのように続行アプリケーションがメッセージの消失や  サーバー障害を知る手段がない堅牢なアプリケーションの構築が不可能に判断の基準
例外情報がモジュール外で必要ない場合  → 定義から消すか、マスキングしてOK 例外情報がモジュール外で必要な場合  → インターフェースに複雑さを追加しても公開すべき 23 / 24

まとめ本章から 4つの技法例外処理はソフトウェアにおける  複雑さの最悪の源泉の一つ例外処理コードは本質的に書くのが難しく  テストも困難不必要な例外の定義が問題をさらに  悪化させる例外を処理しなければならない箇所の数を 
減らすことが鍵エラーを定義から消し去る  APIの意味・定義を見直すのが最善例外のマスキング  低レベルで処理して上位に見せない例外の集約  複数の例外を1箇所でまとめて処理クラッシュさせるだけ  回復不要なエラーは対応を中止する例外を見つけたとき「どう処理するか」の前に「この例外は本当に必要か」と問う 24 / 24

エラーを定義から消し去る

エラーを定義から消し去る

shinaps

More Decks by shinaps

Featured

Transcript