ついでに言うと、モノリシックカーネル vs マイクロカーネル論争でも、マイクロカーネルが好き＞＜；(ハイブリッドも可)
信用する範囲がプロセスあるいはアプリケーション全体で一枚岩構造だと、プロセスごとコケさせるかアプリケーションごとコケさせるしかなくなるので、それをモノリシック的って言葉で説明しようとした＞＜；
orange
さんがブースト
もちろんプロセスより細かく分割することもできて、その場合何か起きたら Result<_, _> なりで実行時エラーとして通知することになるんですが、それって「信用していない」ということなので、信用していないコードのクラッシュに巻き込まれるべきであるという話はしてないです…… (やっぱり「クラッシュ」という言葉がアカン気がしてきた)
オレンジの説明が下手すぎただけなのか、だんだんやっと意図が通じ始めてる気がする＞＜；
orange
さんがブースト
これがスレッド単位とかオブジェクト単位で汚れている範囲が制限できていれば、もっと細かい粒度で破棄できる
orange
さんがブースト
まあプロセス単位で考えると、他のプロセスのメモリは（普通は）汚れていないと仮定できるので、プロセス単位で殺すことには意味がありそう
だとしたらオレンジがいうようにプロセス単位だけじゃなくさらに適切に分割していってって話とも矛盾しないかも＞＜
orange
さんがブースト
「クラッシュ」という言い方が悪かったのかな。「実行文脈の破棄」と正確に表現すべきだったかもしれない (最も自然な選択としてクラッシュではあるけど)
orange
さんがブースト
そのオブジェクトの整合性が保たれているという条件が、そのオブジェクトを使う側の整合性条件に含まれていないのならば、そうです。
オレンジが言いたいことにかなり近い気がする＞＜
orange
さんがブースト
非常用のシステムはダメもとで多重化させるものかも＞＜
orange
さんがブースト
ファイルの処理で行くと、例えばファイルを開いてる途中に JVM が狂ってしまったとして、コード側ではどこかが狂ったということはわかっても JVM が、というのがわかるとは限らないし、そんな状況だったら finally 節が実行されるかも怪しいですよ
さっきのこれも、つまりファイル開いていようがなんだろうが、とりあえずまるごと止めればいいというのであれば、計算機ごとシャットダウンさせればいいんじゃね？＞＜ 一部のファイルが壊れたりファイルシステムごと壊れたりするかもしれないけど、って言いたい＞＜
https://mstdn.nere9.help/@orange_in_space/105635197508593363
わりとさっぱりわからないけど、オレンジ以外の人はfinally節にファイル閉じたりリソース解放する処理を書かないのかも？＞＜
そんなわけ無いでしょ？＞＜
例えばファイルを扱う処理であれば、言うまでもなく途中で何らかの理由不明な問題が起きたらとりあえずファイルを閉じるだけはする処理は書くかも＞＜
ていうかそれ否定したら例外方式の環境のfinally節は何のためにあるんだよって事になるかも＞＜
orange
さんがブースト
その「理由は不明ながら」が既に破綻していて、そんなものを書けること自体がデザインとしておかしくないですか？
想定された種類の例外であればそれに対処する処理を書くべきだし、それ以外の例外であれば「理由は不明ながらもその部分は使用できなかった場合」の処理を書くべきかも＞＜
orange
さんがブースト
例外は「想定されたエラー (明示的に throw されるもの)」と「本当に誰も想定していなかったエラー (意図せぬ場所から propagate されてきたもの)」が混ざるので、失敗や不整合の表現としてはあまり優れた手段ではないという感覚がある
例外じゃない方式のシステムではどうなってるのか知れないけど、例外方式のシステムではそのために例外があるんでは？＞＜
で、疑う部分には例外の処理するかも＞＜
処理した上で上に伝えるのであれば更なる例外投げたりかも＞＜ 何もせずに呼び出し元にそのまま例外素通りさせるんじゃなく＞＜
- ＠orange_in_space
2017年 4月に登録
