orange @[email protected]

で、デフォルトで汚染されていると想定する連鎖が最終的にどこまで広がるかというと実行の文脈全体なので、だからこそ「起きえないことが起きたら文脈を破棄しろ」という話になっている

や、まあ特定のスナップショットについては当然これは可能なんですけど、改変される可能性のあるプログラムについてこのようにブラックリスト形式で汚染を排除していくのはデザインとして正しくないと感じます。
特定の汚染が特定の場所に伝播しないという保証があるなら、安全側に倒してデフォルトで汚染されていると想定するべき。

はい、適切に分割してください。

ただ、その「汚染範囲を小さくする」を誰が行うかの話で、「この変数は、こことここと、この部分に影響してます！」とかいうオプトインな列挙方式でうまく汚染を隔離できると思うなよという思想の話ですね

それでも、「起きえないことが起きた」ときプログラムは最善の努力として「自分が悪影響を及ぼした範囲を更地にすることで『うっかり汚染された領域に踏み込む』ことを阻止する」責任があると考えているけど

不整合や仕様外動作に汚染された領域を破棄する手段として通常は文脈の破棄しか用意されていないという話と、仕様外動作を仕様に含んでいるかのように振る舞うことは根本的におかしいというデザインの話が混ざっていたか

もちろんプロセスより細かく分割することもできて、その場合何か起きたら Result<_, _> なりで実行時エラーとして通知することになるんですが、それって「信用していない」ということなので、信用していないコードのクラッシュに巻き込まれるべきであるという話はしてないです…… (やっぱり「クラッシュ」という言葉がアカン気がしてきた)

これがスレッド単位とかオブジェクト単位で汚れている範囲が制限できていれば、もっと細かい粒度で破棄できる

まあプロセス単位で考えると、他のプロセスのメモリは（普通は）汚れていないと仮定できるので、プロセス単位で殺すことには意味がありそう

「クラッシュ」という言い方が悪かったのかな。「実行文脈の破棄」と正確に表現すべきだったかもしれない (最も自然な選択としてクラッシュではあるけど)

そのオブジェクトの整合性が保たれているという条件が、そのオブジェクトを使う側の整合性条件に含まれていないのならば、そうです。

https://mastodon.cardina1.red/@lo48576/105635212224524087

それについてはこれなので……

ファイルの処理で行くと、例えばファイルを開いてる途中に JVM が狂ってしまったとして、コード側ではどこかが狂ったということはわかっても JVM が、というのがわかるとは限らないし、そんな状況だったら finally 節が実行されるかも怪しいですよ