Fail Fastは、失敗するならできるだけ早く分かるようにする考え方です。
エラーを隠して処理を続けると、後ろの処理で原因が分かりにくい不具合になります。
一言でいうと
Fail Fastは、問題のある入力や状態を早い段階で検出し、原因が分かる形で止める考え方です。
「落ちないようにする」ことと「エラーを隠す」ことは違います。
悪い例
function calculateDiscount(price?: number) {
if (!price) {
return 0;
}
return price * 0.1;
}
price が渡されていない場合も、価格が0円の場合も、同じように 0 を返します。呼び出し側のバグが隠れる可能性があります。
Fail Fastの例
function calculateDiscount(price: number) {
if (price < 0) {
throw new Error("price must be greater than or equal to 0");
}
return price * 0.1;
}
不正な値を早く検出し、原因が分かるメッセージで止めます。
Fail Fastが大切な場面
| 場面 | 早く検出したい理由 |
|---|---|
| 入力チェック | 不正データが奥まで入るのを防ぐ |
| 設定値 | 起動時に設定ミスを見つけたい |
| 権限確認 | 処理後半で拒否すると危険 |
| 外部APIレスポンス | 想定外形式を早く検知する |
| DB制約 | 壊れたデータを保存しない |
入口で検出できる問題は、入口で止めるほうが原因を追いやすいです。
エラーを握りつぶさない
try {
await sendMail(user.email);
} catch (error) {
// 何もしない
}
このように空の catch は危険です。失敗した事実が消えてしまいます。
最低限、ログを出す、利用者へ伝える、再試行する、上位へ投げ直すなど、方針を決めます。
ただし利用者体験も考える
Fail Fastは、ユーザーに雑なエラーを見せることではありません。
内部では早く検出し、画面では分かりやすいメッセージに変換します。たとえば「設定ファイルが壊れています」は開発者向けですが、利用者には「現在処理できません。時間をおいて再試行してください」と出す場合があります。
まとめ
Fail Fastは、問題を早く検出し、原因が分かる形で止める考え方です。
エラーを隠して処理を続けるより、入口で検出して明確に扱うほうが、デバッグと保守が楽になります。