"例外とは、逃げではない。設計に取り込めなかった現実との向き合い方だ。"
一般的なプログラミングにおける例外処理は、「何か起きたら考える」ための後始末として機能する。
だがAdaにおける例外処理は、それとはまったく異なる位置づけを持っている。
エラーは“処理”されるべきではない。構造の中で“発生し得ない”ように設計されるべきである。
その上で、現実の“設計が及ばない不確実性”にだけ、例外が許される。
Adaの基本設計思想：「あり得ないことは書かせない」
Adaでは、設計段階で「発生しうる異常」を構文的に排除することが第一原則である。
たとえば、ゼロ割は以下のように契約（Pre）で除外される。
function Divide (A, B : Integer) return Integer
with Pre => B /= 0;
この設計において、例外は設計漏れの代償ではなく、現実との折り合いである。
例外とは“設計に入れられなかった現象”への礼節
例えば、外部ファイルが存在しない、通信が遮断される、センサが沈黙する——
これらはプログラム内部で完結できない不確定性である。
Adaはこれらに対し、明示的な例外ハンドリングを要求する。
begin
Open_File (Config);
exception
when Name_Error =>
Put_Line("設定ファイルが存在しません。");
end;
この例外処理は「想定外の事態」ではなく、“設計内で許容した”唯一の逸脱である。
SPARKとの断絶：例外なき世界の哲学
SPARKでは、例外は禁止されている。
これは、設計者があらゆる不確実性を排除した“閉じた世界”を構築することを強制されるということ。
例外がないというのは、「ミスが起きない」ことではない。
ミスが起きる余地そのものを構造から削ぎ落とす設計を意味する。
エラー処理から失敗設計へ
現代の多くのプログラムは、try-catchにすべてを託してしまう。
しかし、それは「動くように見えるだけの不安定な構造」でしかない。
Adaはそこに対して、明確な設計上の態度を示す。
設計で避けられる失敗は、絶対に構文で潰せ。
それでも起き得ることに対してのみ、静かに例外を許せ。
結語：例外は、設計が見落とした現実の境界線である
Adaは、例外を「処理」ではなく「構造の外」に位置づける。
それは、設計者の“想定と責任の限界”を明示する枠組みなのだ。
"例外は設計者の責任ではない。だが、例外の存在を許す設計は、誠実でなければならない。"