返す時に例外だしてもよくない？＞＜(もちろんエラーはなるべく早く出したいので、チェックは明示的に(＞＜；)早くやるべきだけど、忘れてたら返す時に最後の砦として的な＞＜)
orange
さんがブースト
orange
さんがブースト
std::sync::PoisonError - Rust
https://doc.rust-lang.org/stable/std/sync/struct.PoisonError.html
mutex を持ったスレッドが解放しないまま死んだ場合、 mutex で管理されている値が不正状態になっている場合があるので、それを表現するために PoisonError<T> でラップされている
正常ではない状態は、究極に無くせない的な＞＜(検出可能か別としても)
オレンジの物事の発想が「世の中は全て、機能と状態の集合で出来ている！＞＜」って発想で、その延長で、ある型のものの状態にも「正常である状態」と「正常ではない状態」があるかも＞＜って発想で、物事を考えてるかも・・・＞＜
orange
さんがブースト
不正な値でありうるか否かというのも、 Result とか Option とかによって型で表現されてほしい
orange
さんがブースト
panic が実質そんな感じの挙動だけど、まあ panic は panic するために使うものであって、復帰はできるけどそういう仕組みは常用されるものではない
orange
さんがブースト
Rust に exception は(基本的に)ないです
orange
さんがブースト
https://doc.rust-lang.org/stable/std/string/struct.String.html#method.from_utf8
たとえばこの String::from_utf8 みたいな感じで
orange
さんがブースト
orange
さんがブースト
そこで、例外でなく Result (Haskell なら Either) などを使うことで、正常値と異常値を値として扱えるようにすることで、コードを整理できるわけです
orange
さんがブースト
TryParseだ…
ある意味null安全に近い話なのかも？＞＜；(オレンジは、内容が不正であることのフラグとして(手抜きで)null許容型を使うこともたまにある＞＜；)
orange
さんがブースト
C++ も (iostream 辺りは歴史的事情か例外のパフォーマンスの事情かアレな感じだけど)、基本的に「不正な状態のオブジェクトを作らず、 ctor で例外を投げろ」という感じになっているし、「正しいものしか存在できない」という感じの世界を作りたさが感じられる
orange
さんがブースト
理想的には型チェックが通った時点で、表明されていたあらゆる制約が満たされていることを確認したいわけで、「URL として妥当であるか」というのは「Url 型のオブジェクトとして存在できるか」と一致してほしい
なんでこんな謎方式にしたいかと言うと、宣言時に例外が出ると後始末がぐちゃってするのが嫌で、それを回避できるならチェックするのは分けたいし、毎回チェックする手間が増えてもって感覚がある＞＜；
orange
さんがブースト
Url 型のオブジェクトが出現したその瞬間から死ぬまで、ずっと Url は URL として valid な値しか持てないでほしい (型を妥当な値の集合として考えれば) ので、 new からの url.Check() で例外を飛ばすのは、ちょっと型の意味が弱すぎるかなぁという気持ちがしますね
xだねっぽさ oだめっぽさ
ダメっぽい＞＜；
さっきのURLの処理みたいなの、オレンジの好みの架空言語ならば・・・＞＜；
ReadOnly StringUTF8 url_string = "example .com";
Url url = new Url( url_string );
url.Check();
//不正な文字列なら例外
bool urlDanepposa = url.IsInvalidURL;
//不正かどうかのプロパティ
bool urlDaijoubupposa = url.IsValidated;
//ポジティブとネガティブもどっちも要るよね！＞＜；
- ＠orange_in_space
2017年 4月に登録
