Rust での unwrap, expect, panic, assert 周辺の話
-
- いいね！0
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
私もお気持ちとしては同感だけど、同時に expect() の方に unreachable であるという文脈というかお気持ちが全く籠められていないので、 expect() を .unwrap_or_else(|_| unreachable!()) 代わりに使うのもコンセンサスが得られていないかもしれないなという感覚もある
2020-12-22 16:43:24
とりさん
@TypedTypelessTy
@lo48576 起きない理由を書くのはコストが高いにしても，せめて”never happen”くらいでエラーにしてほしい．処理を続けられると欠陥箇所の特定に手間がかかる． 書き手の予想が誤っていたことは結果が示しているのだから，書き手が起きないと思っていたということがわかれば十分では？
2020-12-22 16:44:04
Ryusei
@mandel59
そのassertが一体何によって保証されるのか（破られるとしたらどのような対応を取るべきなのか、どこを疑うべきなのか）が曖昧なのが問題で、当然問題ごとに状況は異なっているので一般化は難しい
2020-12-22 16:44:59
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
「アプリケーションでは .expect / .unwrap をクラッシュのお気持ちで使って、ライブラリでは unreachable なお気持ちで使う」みたいな悲惨な使い分けが発生するとかなり嫌な気持ちになってしまうので難しい。 何も考えず main の外側まで伝播させられるエラーなら、頭を空にして anyhow 使うけど
2020-12-22 16:45:10
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
@TypedTypelessTy たぶん unsafe でコンパイラに代わって人間が保証を明示しろよみたいな辺りで調教された結果だと思うんですが、何かしらの保証を前提に動くコードでは必ずその保証が成立する根拠 (だと思っているもの) を明示せよ、みたいな文化が理想であるという世界観があって、メッセージが細かいのはそのためです
2020-12-22 16:47:07
ドッグ
@Linda_pp
自分はロジック上失敗しない（はず）なら .unwrap() でやってるな．そこでエラーになるのは実装上の理由なので，ユーザが見て分かるメッセージが出せないし，実装者が分かれば十分なら理由はコードコメントで十分で，あとはクラッシュした時のバックトレースが知れれば良い
2020-12-22 16:47:12
denjiry
@denjiry
でも書いた時に想定（もしくは頭の隅で思い付いてた）してた不変条件が破られるときって、バグによって破られるかユーザーによって破られるかの2パターンがある（本当にこれだけ？）けど、どちらにしろ不変条件を気にしていてかつ実行時に破られたら死んでくれるという点では共通してるかも？
2020-12-22 16:47:15
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
コメントで十分というのはその通りなんだけど、同時に「特定の処理にできるだけ紐付いた形で理由を示したい」みたいなお気持ちが働いているというのがある。 safety-guard - crates.io: Rust Package Registry crates.io/crates/safety-… こういうやつとかが一例なんだけど。
2020-12-22 16:49:14
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
safety-guard crate は関数にしか使えないけど、たとえば #[safety("this is safe because ...")] unsafe { unsafe_fn_call() } みたいに書けたらステキじゃないですか
2020-12-22 16:50:34
とりさん
@TypedTypelessTy
@lo48576 デバグする側からはもちろんその方がありがたいのだけど，何でも保証って言いだすと停止性やオーダーの証明も書かなきゃならない気がして... 本当は適切な例外で包み直すべき場面でも，面倒くさがって例外を握りつぶされるくらいならそのまま伝搬させてほしいくらいの妥協でした．
2020-12-22 16:53:00
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
/// Asserts that a boolean expression is `true` at runtime, as the specification. macro_rules! spec_assert { ($($toks:tt)*) => { assert!($($toks)*) }; } みたいなのは考えたことあるんですよ。 「仕様としてのクラッシュを assert 的に雑に書きたい」という。
2020-12-22 16:53:54
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
(まあ本当は中身 assert じゃなくて if と panic で実装しろよというお気持ちなんだけど、これは試験的に雑に試してみたやつなので許して)
2020-12-22 16:55:32
らりお・ザ・.*🈗然㊌㋞㋰㋷㋓
@lo48576
@TypedTypelessTy まあ停止性やオーダーが重要な場面だったらやっぱり何かしらの説明が入ると思うので、そういう点では雑に書かれている部分は重要でないということなので手抜きでいいというのもわからなくはないんですが…… せめて「俺が悪い」か「ユーザが悪い」くらいの boolean は絶対に欲しいというのはあります
2020-12-22 16:58:14