新しいものを表示
orange さんがブースト

プロセスという概念で誤解を与えた気はしてきた。
orange 氏の言う適切に失敗を表現する境界を与えろというのはその通りで、でもそれって単に「自分ではない他人が狂っていました」をハンドリングする手段でしかないですよね。
私が死ねと言っているのは「私自身が狂っていることが判明しました」の場合です。

そんで、依存先モジュールが「私自身が狂ってました」と自己申告してきたときユーザがその影響から隔離される手段はちゃんと存在していると考えてください

内部の分け方が不適切だからプロセス単位になっちゃってるんでしょ?>< って言ってる><
それをどうにか伝えようとモノリシックって言葉使った><

全行全命令で検知できるようにとは言っていない><
内部を適切に分割していけば、その分割単位ごとにその部分がコケた時の対処ができるでしょ?>< って言いたい><
なんで一ヶ所コケた時にプロセス単位でしか考えないのか?>< って言ってる><

orange さんがブースト

mstdn.nere9.help/@orange_in_sp

この「仕様が破られたことが検知できたのでエラーを返す」という仕様は、つまり潜在的に「あらゆる関数は実装ミス由来の挙動まで想定して戻り値型を返せ」という話ですよね。
もっと言えば、いかなる関数も Result<RealReturnType, ImplementationBug> 型を返せという。

で、仕様が破られた事が検知できたんでしょ?><
だったらクラッシュさせずにユーザーへのエラー表示も含めた出来る限りの終了処理をすべきでは?><

orange さんがブースト

アプリケーションは「画像化するモジュールが仕様通り動作する」を仕様としており、画像化するモジュールは「内部のデータ構造が有向非巡回グラフである」を仕様としており、その仕様が破られたなら、アプリケーション全体としても仕様違反じゃないですか?

それで言うと中止すべきなのは画像化する処理(のためのデータを扱う処理)であってアプリケーションそのものでは無いでしょ?><

orange さんがブースト

mstdn.nere9.help/@orange_in_sp

これは「不整合の漏出を防げ」案件 (<mastodon.cardina1.red/@lo48576>) で、アプリケーションの内部的な不整合が OS の不整合にならないなら OS はクラッシュする必要がない。

たとえばアプリケーションが画像化しようとしていた有向非巡回グラフだと思っていた構造が実は巡回していた場合、復帰や修正を試みずクラッシュするべき。
でも、その構造が有向非巡回グラフであることは OS にとっての invariant ではないので OS がクラッシュする必要はない。

一方、アプリケーションが利用しようとしていた低レベル機能、たとえばメモリまわりとかドライバまわりの機能の扱いで不整合を発生させてドライバが狂った状態になったとしたら、これ以上ドライバが狂った状態でハードウェアを駆動しないよう OS がドライバを殺すなり OS ごと死ぬなりするべき。

その例で言うと、狂ってるのは42に1を足す処理の部分か計算機そのもののどちらが狂ってるわけであろうから、その部分をスキップさせてエラーを通知して出来る限り穏便に済ませる処理を書くか、計算機をシャットダウンさせる処理を書くべきかも><
単位がアプリケーションというかプロセスって発想ってモノリシック的かも><

orange さんがブースト

「狂っていると判断することに期待する」はたぶん捉え方が逆で、「狂っていないことを期待する場所で何かがおかしかったら全てを諦める」というのが私の考えに近い表現ですね。

let a = 42;
let b = a + 1;
assert!(a == 42);

みたいなのがあったとして、この assert で a が 43 になってたらエラーとして復帰したいですか?
私はそんなのナンセンスだと思うので a == 42 でなかったらさっさとクラッシュしてほしいです

アプリケーションが自らが狂ったと判断するときに、アプリケーションがその旨悲鳴をあげて主張することができて、それを検知したOSが即座に終了処理をせずに計算機をシャットダウンさせる事が可能なシステムで、シャットダウンさせるようにすべき って主張であればオレンジは納得するかも><
そんな環境使いたくないけど><

オレンジ的に言いたいのは、なんで狂人が自分が狂っていると判断することに期待するんだろうって事かも><
狂人かもしれない部分と狂人か判断する部分は別物(別人)であって、その部分が不明な理由で狂っていると判断することが想定可能なのであれば、その狂った部分を回避、例えばできる限り穏便に終了処理を試みるとか、その部分無しに復帰可能であれば復帰させる処理をすべきかも><

orange さんがブースト

信用のないプログラムなんて書けなくて、なぜなら信用しないコードが正しく動いているか検査するコード、その検査は本当に信用できますか……という終わりのない再帰が待ち受けているとか、コンパイラがバグってて不正なコードが吐かれるケースは実際あるけどどう対処するんですかとか、証明や型を付けたとして証明器や型検査が正しく動作しているとどう保証するんですかとか、そういう問題があるから。
そういうところのレイヤーには「ある程度の信用」なしには乗ることができない

スレッドを表示
orange さんがブースト

「信用を裏切られたときのことを想定してエラーハンドリングを書くべきだ」というのは定義上ナンセンスで、それって「信用」してないだけじゃないですか。

スレッドを表示
orange さんがブースト

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

スレッドを表示

成功したって事は成功したかも?><;
それで例えば"123"って文字列を投げて整数型の123じゃなく420とかが返ってきちゃったかどうか? って実行時には検査しないかも><
というか現実的にその整数型にパースするやつが実行時に狂ったかどうか調べるのは現実的じゃないかも><

orange さんがブースト

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

ソフトウェアがモノリシック的かどうかって事になるんだと思う><
クラッシュさせるって事はある一部分に問題があった時に全体を信用しないって事になるかも>< なぜかアプリケーション単位(プロセス単位)で><
クラッシュさせない方の考え方は、内部を区切って行ってお互いを疑いまくり期待しないでおいて、頼んだ先がダメだったら出来る限りのこと、例えばファイルを閉じたり色々なリソースを解放したり、可能であればエラーダイアログを出したりエラーログを書き出したりとか、なるべく穏便な終了処理を試みるかも><

orange さんがブースト

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

スレッドを表示
orange さんがブースト

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

スレッドを表示
古いものを表示
:realtek:

思考の /dev/null