orange @[email protected]

実用的なプログラムは必ずそういう「そこは信用します」というレベルを程度の差こそあれ持っていて、「そこは信用しますレベル」は invariant がどれだけあるか、どれだけ強い条件かで決まってくる。
で、その信用を裏切られたときクラッシュ以外の行為に意味がない、という話です

その「内部を区切ってお互いを信用しない」はモジュール間連携の話で、それは確かに私も同意なんだけど、それをどこまでやるかという話ですよね。
たとえば文字列をパースして整数にする処理が成功した後に「や、ライブラリは『文字列を整数にできた』と報告してきたけど、本当にそれって正しいのか……？」と疑いますかと

たとえばあなたは C++ 標準ライブラリのあらゆるバグを想定して検査をかけますかと。まあ普通はかけない。
何故検査をかけないかというと、ライブラリが仕様通りに動作すると暗黙に信用していて、かつライブラリが狂っているときは自分も狂っていることになるという一連托生状態を受け入れているから。

で、通常は依存ライブラリというのは自分並に信用しているので、依存ライブラリやモジュールが狂っているのは即ち自分が狂っているのと等価に扱うべき

で、狂人に「あなたは狂人ですか？」と尋ねるのは根本的に作りがおかしくて、『わたし』の側で「こいつ狂人じゃん！」と気付くのは常に『わたし』側で実装された処理の責任

https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/#inconsistency-bugs-and-recoverability--unrecoverable-from-inconsistency

> つまり、プログラムが不整合状態になったとき、プログラムは全体として既に想定を満たさない状態で動いている可能性があり、その結果として発生する処理やデータも基本的に無意味である[6]。 その無意味な処理で無意味なデータを解釈して「復帰」しようとする行為も、当然無意味である。

他人が狂人だったらオメーが自衛しろ、自分が狂人かもしれなかったら死ね、と言っています (言葉が悪い)

あと読もうとしているデータのスキーマ次第

見分けがつかない場合もあるでしょうし、あるいは正しく設計すればそもそもそんなことが起き得ない書き方もできるでしょうね。それは言語の表現力とユーザの設計次第。

https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/#additional-topics--still-wondering

端的にはコレです

> * プログラムが完全に掌握しているはずのデータが誤っていれば、 panic せよ
> * プログラムのバグが原因なら、 panic せよ
> * 環境や外部データに問題があるなら Result を返すべし
> * エンドユーザに問題があるなら Result を返すべし
> * ありえないことが起きたなら panic せよ

たとえばですが、
「jsonファイルがフィールド a と b を持っている」
という想定があったとして、「a や b がなかったり余計な c があったりするファイルを読んだ」は「想定可能なエラー」なんですよ。この場合クラッシュすべきでない。

で、じゃあどういう場合にクラッシュすべきかというと、
「json ファイルがフィールド a と b を持っていてそれを読んだのに、返すオブジェクトで a の値を設定し忘れた」とかそういう「デシリアライザが仕様違反を犯している場合」です。
この場合「デシリアライザが『こういうデータを読みますよ』と (仕様で暗黙に) 表明したデータ以外を返す」というのは仕様外動作なので、そこから復帰しようとすべきでない。

そうじゃない！！

ファイル等の読み込みの場面は、ファイルが正しいフォーマットである事に期待する事自体が危険だと思うかも・・・＞＜

それは単に仕様の問題で、もちろん「実装のバグも仕様として想定されたエラーと見做す」という仕様にしてもいいんですよ、そのコストが本当に得られるものに釣り合うなら。