orange
さんがブースト
そういえば Win 9x でブルースクリーンから復帰できるやつを思い出した (もちろん復帰してもファイルの保存などはできない)
あれ復帰する意味あるか？？？？？
よくわからないけど、受けとることすら不可能だったら外側で例外が最終的なキャッチ(ポケモンキャッチ？)されて「なんだかよくわからないけどこの機能はダメっぽい＞＜ 出来る限りの終了処理はしてみた＞＜(その状況のデバッグ用データ)」みたいな感じになるかも＞＜
でもアプリは終了させない＞＜(実用的な処理はなにもしてないけど生きていてGUIは使用できる＞＜)
ように作るようにしてる＞＜
orange
さんがブースト
https://mstdn.nere9.help/@orange_in_space/105635631053077620
> 関門の向こうから受け取ったものが「ダメっぽい＞＜」となったら
これ「ダメっぽいデータが来ることを想定している」ので「想定」の範疇じゃないですか、想定していない状況の話ではないですよね……
想定していない状況というか、想定していない状況が起きるかもしれないので、関門の向こうから受け取ったものが「ダメっぽい＞＜」となったら「これこういう風にダメっぽい＞＜」ってデバッグ情報話して、「ダメっぽいので出来ない＞＜」ってエラーだす＞＜
でも、アプリは終了させない＞＜
そのために内部データ形式に「これぶっ壊れてるフラグ」をつけたり、壊れてるときにはアクセスしてはいけない部分にアクセスすると例外吐くようにしてる＞＜
で、扱う側はチェックしたり例外受け取って「この処理出来ないっぽい＞＜」ってなる＞＜
でもアプリは終了させない＞＜
orange
さんがブースト
想定していない状態が発生したということは、プログラムを書くときに開発者が置いた前提と実世界が食い違っていたということで、それって既に「間違った前提で書いたコードが見掛け上正しく動いてるだけ」ですよ
デバッグ実行してるから＞＜；
orange
さんがブースト
なんで既に仕様通りに動いていないプログラムを見て「や、でも終了処理とリソース解放だけはちゃんと行われているはずだ！」と信用できるんですか……
発狂してる部分とそこから影響受ける部分の機能は、ちゃんと機能せずに止まるかも＞＜
それと無関係の部分が生きてるだけで＞＜
orange
さんがブースト
「正常ですという顔をして裏では発狂していて、ユーザの想定しない悪行を為している」とか絶対許さないマンですよ私は！
いや、でも、終了処理はきちんと行われるし、メモリリークとかリソース解放の失敗とかは基本的に起きないよ？＞＜；
orange
さんがブースト
なんだよ根本から噛み合ってねえじゃねえか！！！w
orange
さんがブースト
それ、まさしく私が許したくない状態ですが……
文脈難しいけど、オレンジが書くアプリだとたまになる現象っぽい気がしなくもないかも？＞＜；
アプリ自体はクラッシュしないでエラーメッセージは出るけど、その後、アプリの実用上なにも出来ない状態になったり＞＜；
(アプリの正常終了とか、場合によってはファイルの保存だけ出来たり、逆に保存すら出来ないけど新たなファイルを読み込むと何事もなかったように正常動作するとか＞＜；)
orange
さんがブースト
で、「一部の (意味ある) 値の参照が許されなくなったけど続行してね！」というのは通常不可能なので、文脈そのものを破棄するというデフォルトは合理的でもあるわけです。
そうしないオプションが提供されているとしても、デフォルトでは文脈の破棄になるのは妥当。
orange
さんがブースト
「文脈を巻き込まず一部のデータだけパージすればええやん」というのはまあ理屈の上では正しいんですが、実用性は微妙だと思うんですよね。
そもそもプログラムが動作するうえで、ふつう参照する値の全てには意味があるので (意味のない参照なら消せよとなる)。
「一部の値は参照すら許されない状態になったけど続行してね！」とかかなり過酷で不自然な状況で、これを正しく実装するのって通常のエラー処理どころではないコストがかかりますよ
orange
さんがブースト
必ずしもそれだけの問題ではなく、たとえばポインタと型情報であるとか、配列とインデックスであるとか、そういう「組み合わせてはじめて整合性が定義される」ようなものはよくある (というか整合性はそもそも複数のデータの集合について規定されるのが普通) ので、インデックスの計算でトチって配列を変更しなかったとか、インデックスは正しく算出できたけど配列の作成でトチったとか、そういう状況ではやっぱり「汚染」は伝播している
よくわかんなくなってきたけど、だからこそ副作用をなるべく無くすように書くとかそういう話があれかも？＞＜
orange
さんがブースト
で、デフォルトで汚染されていると想定する連鎖が最終的にどこまで広がるかというと実行の文脈全体なので、だからこそ「起きえないことが起きたら文脈を破棄しろ」という話になっている
orange
さんがブースト
や、まあ特定のスナップショットについては当然これは可能なんですけど、改変される可能性のあるプログラムについてこのようにブラックリスト形式で汚染を排除していくのはデザインとして正しくないと感じます。
特定の汚染が特定の場所に伝播しないという保証があるなら、安全側に倒してデフォルトで汚染されていると想定するべき。
orange
さんがブースト
はい、適切に分割してください。
ただ、その「汚染範囲を小さくする」を誰が行うかの話で、「この変数は、こことここと、この部分に影響してます！」とかいうオプトインな列挙方式でうまく汚染を隔離できると思うなよという思想の話ですね
- ＠orange_in_space
2017年 4月に登録
