[過去ﾛｸﾞ] Rust part30 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
921: 06/19(木)23:34 ID:67nyX+fT(3/3) AAS
そのmutex毒入り状態からの復帰処理をしたい場合はunwrapせずにErr時に処理とclear_poison()する
922(1): 06/20(金)00:31 ID:xog7LFS0(1/5) AAS
これおもしろー
外部ﾘﾝｸ:blog.guillaume-gomez.fr
ポインターアクセスより配列の方が速いんやー
923(1): 06/20(金)01:02 ID:SpbybkFq(1) AAS
unwrapではなくexpectを使う。
924(1): 06/20(金)01:08 ID:xog7LFS0(2/5) AAS
>>923
いや、Optionにはunwrap使ってええんやで
コードに合わせて柔軟に対応すりゃバグは防げるよ
ビジネスロジックのバグは入念なテストしないと見つけられないけどね
ビジネスロジックのバグでシステム障害になることもまあ、あるっちゃあるよねテストしてなきゃ
925: 06/20(金)01:13 ID:/9Nz/yYP(1/2) AAS
>>922
昔読んだが00～99のテーブルをコピーするところだな
配列境界検査は起きないコードだから速度は同じ
926: 06/20(金)01:18 ID:/9Nz/yYP(2/2) AAS
>>924
panic許容シーンでない場合
絶対Some保証できない場ではunwrapもexpectも使わないよな
927(1): 06/20(金)07:50 ID:d5bZ3vB1(1/2) AAS
expectに書く文がいまいち分からんのだよな
エンドユーザーがその一文だけ見て何か意味があるとも思えないし
デバッグする開発者向けなら結局前後の文脈込みで見るしかないから
unwrapにして詳細をコメントに書いたほうがいい気がしている
928(1): 06/20(金)08:04 ID:Op1qS17W(1) AAS
>>927
ユーザに文章を示してpanicさせたいの？
文章をprintかeprintしてからpanic!呼んだら？
929(1): 06/20(金)08:15 ID:d5bZ3vB1(2/2) AAS
>>928
いや、そうじゃなくて「unwrapの代わりにexpectを使ってunwrapしても大丈夫な理由を明記すべき」みたいな言説があるじゃん？
そのときにexpectに書くべき文がわからんって話
ユーザ向けにエラーとして表示したいならそりゃ普通にResult使うし、
どうしてもパニックしたいならprintlnすればいいのはその通りだけど
930: 06/20(金)08:22 ID:xog7LFS0(3/5) AAS
基本フロントエンド側とAPIのエラーコード、エラーメッセ仕様は最初に決めておくから、あとは「どの関数レイヤーで」そのIFに合わせこむかだけじゃない？
ここのスレ多分Rustを業務用で使ってる人ばっかだから仕様の取り決めとから雇用主から降ってくるもんだと思うけど。返すエラー定義決まってなきゃそもそもテストコード先に書けないし、納品物にもテスト結果入れれなくて困るしな
931: 06/20(金)08:25 ID:xog7LFS0(4/5) AAS
個人的にはtracing::debug!で自分用のデバッグ出力はON/OFFしてるけど、エラーコードやエラーメッセージは案件別に全然仕様が違うwwwやめてwwwから、仕方なくErrで一旦上げてresponse.bodyに詰め込む直前で相手さんの期待する結果になるようにparseしてることが多い
フロントエンド側で翻訳ぐらいせえやーって思うけど、たまにバックエンドで各言語に合わせて翻訳やってくれー案件もあったりするしバラバラで何考えてんのかはよー分からん
932(1): 06/20(金)09:04 ID:ymNSNGAk(1) AAS
>>929
外部ﾘﾝｸ[html]:doc.rust-lang.org
に尽きると思うが、何がわからんのかわからん
原則としては例外ケースが生じない確信があろうとエラーコンテキストは引き継がれるべきで、
panicさせるのは当該ケースの対処のしようがないことがその場で明らかなケースのみ
そして君のコード内でコントロールのしようがない事象である以上は基本的にそれは外部要因によるものだろうから、その要因を記載すればいい
933: 06/20(金)09:47 ID:Dy/CHU8X(1/2) AAS
>>932
外部要因ならコード作者は制御できないんだからResultで表現すべきではない？
unwrapするケースって「このコードパスではxは（自分が書いたロジックが間違ってなければ）確実にSomeだから安全にunwrapできるはず」みたいなのだと思うんだけど、
その文をexpectに書いたとして誰が読むんだ？って疑問
934: 06/20(金)10:32 ID:p4ugM+VW(1) AAS
panic時のメッセージは未来の自分を含めて他の開発者向け
ここの2つを読んでおくといいと思う
外部ﾘﾝｸ:burntsushi.net
外部ﾘﾝｸ:www.thecodedmessage.com
935: 06/20(金)11:10 ID:Dy/CHU8X(2/2) AAS
開発者向けにコードの意図を説明するのって普通はコメントだと思うんだよね
例えばunsafeを使っても安全な理由とかもコメントで書くし
なのにunwrapに限ってわざわざ文字列リテラルで書く理由が分からない（複数行や長文も書きづらいし）
コメントとの違いは実行時に表示できることではあるけど
実行時にその一文を出せて嬉しいか？
開発者なら結局周辺含めてコード読むんじゃない？
936(2): 06/20(金)11:19 ID:FlGaOpZd(1) AAS
書いてて思ったけど「このメッセージが表示されたらライブラリのバグなんでこのGithubまで報告してね」
みたいなメッセージなら意味あるかな、という気がした
エンドユーザーが見てちゃんと理解できるから実行時に出す意味もあるし、
ライブラリの内部エラーだからアプリケーション側には責任がないことも表明できるし
937: 06/20(金)11:25 ID:xog7LFS0(5/5) AAS
>>936
これいいな。OSSならそんな感じだしエンタープライズなら開発担当部門書いとこ
938: 06/20(金)12:33 ID:3ZKjcbd7(1) AAS
バグなんて他にもいくらでもあるんだから、それこそunwrapに限ってそんな懇切丁寧なケアをする理由がない
やらかした犯人なんてgit blameですぐわかる
939(1): 06/20(金)13:09 ID:LFsGGVpd(1/2) AAS
expectは使用者とか使用状況に対する期待だと思ってた
メッセージはコメントのPanicsに対応させる感じ
/// ...
///
/// # Panics
/// - Panics if the given size is 0.
///
pub fn make_buffer(size: usize) -> Buffer {
let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");
// ...
省1
940: 06/20(金)15:04 ID:3ZuChe0s(1/2) AAS
>>939
基本的にはその考え方で正しい。
でも標準ライブラリや処理系すらそうしてないし、現実は理想通りではない。
941(1): 06/20(金)16:00 ID:r2H2v8it(1) AAS
Haskellにはならなかったな
Rustにもならないのでは？
942: 06/20(金)16:21 ID:+wQsfMK/(1) AAS
>>941
Rustは本来的にはコーディングの誤りに対して939のようにわりと問答無用でpanicする指向だと思うけど、
関数型というかHaskellかぶれのオモチャにされてるせいで実行時panicダサいみたいな空気が醸成されてきている一方で、
なんでも型のコンテキストで上手に扱えるほど型に表現力があるわけでもないから中途半端な感じになってるね
943: 06/20(金)16:41 ID:3ZuChe0s(2/2) AAS
システムプログラミング言語としての性質があるから仕方がない面はある。
ハードウェアやら OS やらが Rust の性質に従ってくれるとは限らないので言語の側で合わせないと仕方がない。
944: 06/20(金)16:53 ID:IXOAfd5T(1) AAS
Rustバランスいいよな
抽象度の高い記述ができつつC言語の代替もできる
945: 06/20(金)17:25 ID:LFsGGVpd(2/2) AAS
Haskellもボトム型あるから変わらんだろ
どの型の値も計算できない可能性を内包してる
946: 06/20(金)18:40 ID:0ePzwW3B(1) AAS
>>936
そういうのはまとめてpanic handlerに書いたほうがいいんじゃないかな
最近はあまり使われてないかもしれないけどhuman-panicとかがそれ用
あとstdのリファレンスにもexpectに書くメッセージのスタイルについて解説があった
外部ﾘﾝｸ[html]:doc.rust-lang.org
947(2): 06/21(土)18:45 ID:usD2bL3Y(1) AAS
>pub fn make_buffer(size: usize) -> Buffer {
>let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");
事前条件がNonZeroなら
pub fn make_buffer(size: NonZeroUsize) -> Buffer
にしたほうが堅さという意味ではよくない？
948: 06/21(土)19:54 ID:aOIRcMzj(1) AAS
外部入力が起源のデータに対しては必ずエラーを返す
プログラム自身発ならバグであり続行不可なのでpanicしてもよい
949(1): 06/21(土)19:55 ID:CfyG8iYl(1) AAS
>>947
NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
NonZeroにしたところで結局呼び出し元でのチェックが0との比較からOptionのチェックに変わるだけのことでしかなく、
コードが冗長かつ余計なoptionが入ることでノイズが増え意図が不明瞭になるし、
unwrapしちゃったらpanic時のエラーもわかりづらい
ダメってわけじゃないが呼び出し元のことを考えると独善的な感が否めない
950: 06/21(土)22:49 ID:qYLKV/K+(1/2) AAS
>>949
>NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
Optionと一緒に使うためのものというのはよく意味がわからない
例えばOptionに置き換えて考えてみたとしてこういう実装があったらおかしいと思わない？
fn make_buffer(size: Option<usize>) -> Buffer {
let size = size.expect("size must not be None”)
…
}
簡単に型で表現できないものならまだわかるんだけど
上下前次1-新書関写板覧索設栞歴
あと 52 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s