【コード哲学エッセイ】 エラーは 「敵」 じゃない、 境界の 「案内役」 だ —— 失敗を設計に組み込む

エラーが出た。
画面を赤く染める文字。
止まった処理。

かつての僕は、それを敵のように感じていました。
「また出た。潰さなきゃ」
「エラーが出ないように、なんとかしなきゃ」

エラーと戦い、エラーを封じ込め、エラーを出さないコードを書く。
それが、正しい開発だと思っていました。

エラーを 「潰す」 ことに必死だった頃

エラーが出ると、まず「どうやって消すか」を考えていました。
例外を握りつぶす。
エラーをログに吐いて無視する。
「とりあえず動けばいい」と、エラーの中身より、
エラーが出ないことを優先していたのです。

結果、何が起きたか。

エラーは、表面から消えた。
でも、境界は、闇のなかに残った。

「ここから先は想定外ですよ」
「ここで失敗する可能性がありますよ」

その境界を、僕は見ないふりをしていた。
エラーを敵だと思っていたから、
エラーが教えてくれている「ここが境目だ」という情報を、
受け取れていなかったのです。

エラーは、 「ここが境界だ」 と教えてくれている

転機は、とあるプロジェクトで、
エラーハンドリングを「後から」ではなく
「最初から」設計し直したときでした。

「この処理は、ここで失敗しうる」
「失敗したとき、どこまでを保証して、
　どこからを呼び出し側に任せるか」

それを、コードの境界として明示する。
エラーを握りつぶさず、「ここで失敗した」という事実を、
型や戻り値や例外で伝える設計に変えたのです。

すると、不思議な感覚がありました。

エラーが、敵ではなく、案内役に変わった。

「ここが境界ですよ」
「ここから先は、想定外の世界ですよ」
「呼び出し側で、どう扱うか決めてください」

エラーは、そう教えてくれている。
潰すべき相手ではなく、境界を指し示してくれる存在だったのです。

失敗を設計に組み込む、 とは

「失敗を設計に組み込む」とは、失敗をなくすことではありません。
失敗が起きうる場所を認め、
その境界を設計のなかに明示しておくことです。

📌 どこまでが「正常」で、どこからが「異常」か。

📌 異常のとき、誰が責任を持って扱うか
　（呼び出し元か、この関数か、上位層か）。

📌 エラーを、どういう形で伝えるか
　（戻り値か、例外か、ログか）。

それを、エラーが出てから慌てて考えるのではなく、
設計の段階で境界として描いておく。

エラーを敵だと思っていると、
「出さない」ことに力を使い、境界はぼやけたままになる。
エラーを案内役だと思うと、
「ここが境界だ」と教えてくれるから、その境界を設計に書き込める。

失敗を設計に組み込む。
それは、失敗を恐れず、失敗が教えてくれる境界を、
コードのなかに残すということなのです。

境界の案内役として、 エラーと向き合う

いま、僕はエラーが出たときに、まずこう自分に問いかけます。

「このエラーは、どこが境界だと言っているんだろう」
「その境界を、設計に書き込めているだろうか」

潰すことばかり考えない。
エラーが案内してくれている「境界」を、受け取る。

そして、設計の段階から
「ここで失敗しうる」
「失敗したらこう伝える」
と書いておく。
エラーは、敵ではありません。
境界を指し示してくれる、案内役なのです。

失敗を設計に組み込む。
エラーを恐れず、境界を明示して、前に進む。
そんな向き合い方を、僕は大切にしています。

あわせて読みたい

▼ バグやエラーを「手紙」として読みたいときに

バグを責めるのではなく、システムが伝えようとしていることを読む。
デバッグの視点を変える話です。

▼ テストを「保険」ではなく「祈り」として書きたいときに

テストを、守りのためではなく未来の自分への手渡しとして書く。
テストの向き合い方を変える話です。

▼ 依存やつながりを「設計」の視点で見直したいときに

依存の「数」ではなく「質」を問う。
必要なつながりを恐れない設計の話です。

ひとりごと

エラーを敵だと思っていた頃のコードを、
今でも時々目にします。

例外を握りつぶして
「動いたからいいか」としていたあの頃。
境界がぼやけたまま、
次の人が「ここ、どこで失敗するか分からない」
と困っている姿を、想像するだけで胸が痛みます。

エラーを案内役として迎え入れてから、
設計がずいぶん素直になった気がしています。

みなさんのエラーが、
境界を教えてくれる案内役になりますように。