URLだとあれだけど、URLの型の変数を作ろうとして準備してしまった何らかのリソースを失敗した結果好きな順番(環境上の都合に適した順番)で後始末したいって発想がある＞＜；(小さなもの(？)なら例外の所から逆に破棄していけばなんとかなるけど、そうじゃない何らかのハードウェア上の都合とかがある場合に・・・＞＜)
orange
さんがブースト
Rust の話になってしまうけど、エラーも結局単なる型と値として扱われるので、特になにかフローが滅茶苦茶になったりすることはないです
orange
さんがブースト
あと例外のフローについては、それは単に例外の扱いが悪い言語に慣れているのではみたいな気持ちです
orange
さんがブースト
私は「Url 型の値として存在させる」こと自体が「URL として不正でないものとして扱っている」と見做しているので、その辺りか
壊れていても壊れていなくても後始末はしないといけないので、壊れてるって状態もあるモデル(という普段オレンジが物事を考える時に使う発想)が、ちょうどそれにぴったりかも的なアレかも＞＜
(なので、逆に「状態なんてバグの原因にしかならない」って発想から見たら、状態なのでバグの原因かも＞＜)
基本的にはURLとして不正な文字列を内部に持つUrlは存在しない方がいいかも＞＜ なので不正ではないかのように扱おうとした瞬間に例外をはいてほしいんけど、
ただし！＞＜；宣言や、コンストラクタを呼ぶ場面だけは例外出されて後始末の流れがぐちゃぐちゃになるのがいやなので、そんな変な事に＞＜；
orange
さんがブースト
1. String → Url
2. Url に対してなんらかの操作 (たとえば path を得るなど)
のどちらでエラーが出るかという話はわかるんですが、 URL として壊れた文字列の扱いについての言及がよくわからない
オレンジ的にはURLはURLであって(さっきの例に限って言うのであれば)文字列ではなくて、不正な文字列から作られたurlは、urlを作りたかったけど失敗してぶっ壊れたもので、文字列は明示的にrawな文字列として取り出す場合以外では、例えば文字列型にキャスト出来るのであれば、その時にも例外を出してほしいかも＞＜；
orange
さんがブースト
たとえば「文字列を URL にしたい」が失敗したとき出てくるのは「URL にしたかったけどできなかった『文字列』」であるわけで、であればこれは Url 型で表現できなくても文字列型として表現できるわけで、「正しい状態しか表現できない」というのはそういう程度の話です
orange
さんがブースト
「正常でない」にも複数種類あるわけで、いわゆる異常系と正常系みたいな話になるけど……
返す時に例外だしてもよくない？＞＜(もちろんエラーはなるべく早く出したいので、チェックは明示的に(＞＜；)早くやるべきだけど、忘れてたら返す時に最後の砦として的な＞＜)
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_in_space
2017年 4月に登録
