https://mstdn.nere9.help/@orange_in_space/105635250963690795
この「仕様が破られたことが検知できたのでエラーを返す」という仕様は、つまり潜在的に「あらゆる関数は実装ミス由来の挙動まで想定して戻り値型を返せ」という話ですよね。
もっと言えば、いかなる関数も Result<RealReturnType, ImplementationBug> 型を返せという。
https://mstdn.nere9.help/@orange_in_space/105635197508593363
これは「不整合の漏出を防げ」案件 (<https://mastodon.cardina1.red/@lo48576/105635171147138318>) で、アプリケーションの内部的な不整合が OS の不整合にならないなら OS はクラッシュする必要がない。
たとえばアプリケーションが画像化しようとしていた有向非巡回グラフだと思っていた構造が実は巡回していた場合、復帰や修正を試みずクラッシュするべき。
でも、その構造が有向非巡回グラフであることは OS にとっての invariant ではないので OS がクラッシュする必要はない。
一方、アプリケーションが利用しようとしていた低レベル機能、たとえばメモリまわりとかドライバまわりの機能の扱いで不整合を発生させてドライバが狂った状態になったとしたら、これ以上ドライバが狂った状態でハードウェアを駆動しないよう OS がドライバを殺すなり OS ごと死ぬなりするべき。
信用のないプログラムなんて書けなくて、なぜなら信用しないコードが正しく動いているか検査するコード、その検査は本当に信用できますか……という終わりのない再帰が待ち受けているとか、コンパイラがバグってて不正なコードが吐かれるケースは実際あるけどどう対処するんですかとか、証明や型を付けたとして証明器や型検査が正しく動作しているとどう保証するんですかとか、そういう問題があるから。
そういうところのレイヤーには「ある程度の信用」なしには乗ることができない
実用的なプログラムは必ずそういう「そこは信用します」というレベルを程度の差こそあれ持っていて、「そこは信用しますレベル」は invariant がどれだけあるか、どれだけ強い条件かで決まってくる。
で、その信用を裏切られたときクラッシュ以外の行為に意味がない、という話です