panic!とrecoverable errorの分断

Posted at 2025-04-24

"すべてのエラーは同じではない。回復可能性が分けるのは、構造への信頼か、破壊かである。"

多くの言語では、「例外」はひとつの枠にまとめられ、回復可能なものと致命的なものが混在している。
その結果、どこで処理を止めるべきか／継続するべきかの判断がコード上で曖昧になる。

Rustはこれに明確な境界線を引いた。

この分断は、単なる構文的選別ではない。
エラーを“扱うもの”と“止めるべきもの”に設計段階で分けるという、構造的な誠実さの宣言である。

panic!は「発生してはならないこと」を表明する構文

fn get(index: usize, values: &[i32]) -> i32 {
    values[index] // 範囲外アクセス → panic!
}

このようなコードは、安全な範囲チェックがなければ実行時にpanicを発生させる。
Rustの哲学において、panicは「設計上“絶対に起きない”と考えられていたが、起きてしまった例外」である。

つまり、panicは論理的保証の失敗であり、プログラムを続行すべきではないという判断が静的に表明される。

fn read_config() -> Result<String, std::io::Error> {
    std::fs::read_to_string("config.toml")
}

このように Result で返されるエラーは、「発生し得るが、対処可能な事象」として設計に組み込まれる。

例：

これらは、**「予想された異常」**であり、設計上「エラーであっても処理を続行できる」ことが求められる。

Rustコミュニティの多くでは、panic! は「到達してはならないコードへの到達」を意味するものとして設計するべきとされている。

たとえば：

match some_enum {
    Known(v) => handle(v),
    Unknown => panic!("Unreachable: unknown variant"),
}

これは、「設計上このパターンには到達しないはず」という意志の表明であり、
もしpanicが起きたならば、設計者が見落としていた世界が存在したことになる。

多くの言語では例外を catch して無視することができる。
Rustでは panic を捕捉することも可能だが、それは最後の手段であり、
基本的には 「例外が起きないよう設計する」 ことが大前提となっている。

Rustにおいて「catchする」という行為は、設計の再考を促すサインである。

例外があると、「失敗しても誰かがなんとかするだろう」という設計の他人任せが生まれる。
Rustでは、Result を返す設計者が、「ここは失敗する可能性がある」と明示的に言語化する必要がある。

これは、意図のないエラー発生を未然に防ぎ、責任の所在をコードに刻む行為である。

unwrap() や expect() は Result や Option を強制的に展開する。
しかしこれは、エラー処理をスキップしてpanic!に委ねる危険なショートカットである。

let content = std::fs::read_to_string("file.txt").unwrap(); // panicのリスク

このようなコードが許されるのは、“失敗する可能性が設計上存在しない”と確信したときだけである。

それ以外で使えば、設計の信頼性を破壊する毒に変わる。

つまり、Rustにおいて panic! は、アプリケーションの終了を設計に組み込む構文でもある。

それは、**システムが「壊れてはいけない」箇所における“破壊の設計”**なのだ。

Rustは例外を捨てた。しかし失敗の可能性を捨てたのではない。
むしろ、「失敗を構文で責任として定義せよ」という思想に転換した。

panic! とは、その責任を明示できなかった場合の最終的な設計上の敗北点である。

それを避けるために、設計者はあらゆる失敗を Result で表し、処理可能な構造へと昇華させる必要がある。

"panicは設計者の敗北ではない。設計に対して誠実であろうとした意志の証である。"