[過去ﾛｸﾞ]
Rust part30 (1002ﾚｽ)
Rust part30 http://mevius.5ch.net/test/read.cgi/tech/1748392296/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
909: デフォルトの名無しさん [sage] 2025/06/19(木) 01:38:01.02 ID:QXnAvsJc >>904,906 君は何を言ってるんだい？ Googleのレポート見ろよ&&公式読めよブーメランが刺さってるぞ http://mevius.5ch.net/test/read.cgi/tech/1748392296/909
910: デフォルトの名無しさん [sage] 2025/06/19(木) 02:14:01.17 ID:Pd2QOZgo >>908 新しいポリシーを反映させないか 反映させても空白のみエラーで飛ばせば障害は起きていない http://mevius.5ch.net/test/read.cgi/tech/1748392296/910
911: デフォルトの名無しさん [sage] 2025/06/19(木) 04:21:35.41 ID:yro0K3vV Rustにしとけってことか、速い話が http://mevius.5ch.net/test/read.cgi/tech/1748392296/911
912: デフォルトの名無しさん [sage] 2025/06/19(木) 05:04:25.47 ID:ct5m24p0 落ちるプログラムを各リージョンにバラ撒かなければ何製でも防げてる もちろんRustなら確実に防げた http://mevius.5ch.net/test/read.cgi/tech/1748392296/912
913: デフォルトの名無しさん [sage] 2025/06/19(木) 06:59:17.36 ID:tFafecL1 とにかくRustにすれば安心安全 これはもう常識 http://mevius.5ch.net/test/read.cgi/tech/1748392296/913
914: デフォルトの名無しさん [sage] 2025/06/19(木) 11:59:43.17 ID:cYRDzc4D ちゃんとした人が、Rustを使った場合に限る。 セキュリティもそうだけど、人が関わると碌なことがない。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/914
915: デフォルトの名無しさん [sage] 2025/06/19(木) 12:27:53.31 ID:/pQfT2SX Rustは安全に配慮したコンセプトはいいけど、それを徹底できていない。 せめてSafe Rust強制モードとpanic禁止モードは用意しておくべきだった。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/915
916: デフォルトの名無しさん [sage] 2025/06/19(木) 21:29:19.19 ID:67nyX+fT CPUとメモリは自由なunsafeが本質なので下位のライブラリは標準もデファクトもunsafeで作られている http://mevius.5ch.net/test/read.cgi/tech/1748392296/916
917: デフォルトの名無しさん [sage] 2025/06/19(木) 21:38:06.06 ID:67nyX+fT panicは意図せず混入防止も兼ねてこんな運用が多いかな [lints.clippy] missing_panics_doc = "warn" http://mevius.5ch.net/test/read.cgi/tech/1748392296/917
918: デフォルトの名無しさん [sage] 2025/06/19(木) 21:49:11.90 ID:nNn4PbNI 標準ライブラリが内部では unsafe だらけというのは確かにそう。 外側に対しては安全になるように配慮してるけど、バグが絶対にゼロかというとそんなことはないし、実際に発見されたこともある。 まあ unsafe に限らず処理系や標準ライブラリにバグがあることを疑ってたらきりがないからそこらは割り切らないと仕方なくない？ http://mevius.5ch.net/test/read.cgi/tech/1748392296/918
919: デフォルトの名無しさん [sage] 2025/06/19(木) 21:56:40.37 ID:6vmjzLKI みんな律儀にResultは全てちゃんとハンドリングしてるの？ Mutex.lock() なんかは気にせず unwrap してるんだけど http://mevius.5ch.net/test/read.cgi/tech/1748392296/919
920: デフォルトの名無しさん [sage] 2025/06/19(木) 22:11:01.42 ID:nNn4PbNI >>919 ロックが失敗するのはスレッドがパニックしたとき。 つまりハンドリングするならそのスレッド内のエラーであるべきで、 Mutex.lock の失敗に対してハンドリングしても出来ることがない。 そこは普通は unwrap してよいところだと思う。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/920
921: デフォルトの名無しさん [sage] 2025/06/19(木) 23:34:30.87 ID:67nyX+fT そのmutex毒入り状態からの復帰処理をしたい場合はunwrapせずにErr時に処理とclear_poison()する http://mevius.5ch.net/test/read.cgi/tech/1748392296/921
922: デフォルトの名無しさん [sage] 2025/06/20(金) 00:31:53.70 ID:xog7LFS0 これおもしろー https://blog.guillaume-gomez.fr/articles/2025-06-19+Rust%3A+Optimizing+integer+to+string+conversions ポインターアクセスより配列の方が速いんやー http://mevius.5ch.net/test/read.cgi/tech/1748392296/922
923: デフォルトの名無しさん [] 2025/06/20(金) 01:02:39.89 ID:SpbybkFq unwrapではなくexpectを使う。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/923
924: デフォルトの名無しさん [sage] 2025/06/20(金) 01:08:46.49 ID:xog7LFS0 >>923 いや、Optionにはunwrap使ってええんやで コードに合わせて柔軟に対応すりゃバグは防げるよ ビジネスロジックのバグは入念なテストしないと見つけられないけどね ビジネスロジックのバグでシステム障害になることもまあ、あるっちゃあるよねテストしてなきゃ http://mevius.5ch.net/test/read.cgi/tech/1748392296/924
925: デフォルトの名無しさん [sage] 2025/06/20(金) 01:13:11.37 ID:/9Nz/yYP >>922 昔読んだが00～99のテーブルをコピーするところだな 配列境界検査は起きないコードだから速度は同じ http://mevius.5ch.net/test/read.cgi/tech/1748392296/925
926: デフォルトの名無しさん [sage] 2025/06/20(金) 01:18:17.09 ID:/9Nz/yYP >>924 panic許容シーンでない場合 絶対Some保証できない場ではunwrapもexpectも使わないよな http://mevius.5ch.net/test/read.cgi/tech/1748392296/926
927: デフォルトの名無しさん [sage] 2025/06/20(金) 07:50:16.10 ID:d5bZ3vB1 expectに書く文がいまいち分からんのだよな エンドユーザーがその一文だけ見て何か意味があるとも思えないし デバッグする開発者向けなら結局前後の文脈込みで見るしかないから unwrapにして詳細をコメントに書いたほうがいい気がしている http://mevius.5ch.net/test/read.cgi/tech/1748392296/927
928: デフォルトの名無しさん [sage] 2025/06/20(金) 08:04:54.66 ID:Op1qS17W >>927 ユーザに文章を示してpanicさせたいの？ 文章をprintかeprintしてからpanic!呼んだら？ http://mevius.5ch.net/test/read.cgi/tech/1748392296/928
929: デフォルトの名無しさん [sage] 2025/06/20(金) 08:15:40.44 ID:d5bZ3vB1 >>928 いや、そうじゃなくて「unwrapの代わりにexpectを使ってunwrapしても大丈夫な理由を明記すべき」みたいな言説があるじゃん？ そのときにexpectに書くべき文がわからんって話 ユーザ向けにエラーとして表示したいならそりゃ普通にResult使うし、 どうしてもパニックしたいならprintlnすればいいのはその通りだけど http://mevius.5ch.net/test/read.cgi/tech/1748392296/929
930: デフォルトの名無しさん [sage] 2025/06/20(金) 08:22:37.63 ID:xog7LFS0 基本フロントエンド側とAPIのエラーコード、エラーメッセ仕様は最初に決めておくから、あとは「どの関数レイヤーで」そのIFに合わせこむかだけじゃない？ ここのスレ多分Rustを業務用で使ってる人ばっかだから仕様の取り決めとから雇用主から降ってくるもんだと思うけど。返すエラー定義決まってなきゃそもそもテストコード先に書けないし、納品物にもテスト結果入れれなくて困るしな http://mevius.5ch.net/test/read.cgi/tech/1748392296/930
931: デフォルトの名無しさん [sage] 2025/06/20(金) 08:25:55.42 ID:xog7LFS0 個人的にはtracing::debug!で自分用のデバッグ出力はON/OFFしてるけど、エラーコードやエラーメッセージは案件別に全然仕様が違うwwwやめてwwwから、仕方なくErrで一旦上げてresponse.bodyに詰め込む直前で相手さんの期待する結果になるようにparseしてることが多い フロントエンド側で翻訳ぐらいせえやーって思うけど、たまにバックエンドで各言語に合わせて翻訳やってくれー案件もあったりするしバラバラで何考えてんのかはよー分からん http://mevius.5ch.net/test/read.cgi/tech/1748392296/931
932: デフォルトの名無しさん [sage] 2025/06/20(金) 09:04:21.71 ID:ymNSNGAk >>929 https://doc.rust-lang.org/std/error/index.html#common-message-styles に尽きると思うが、何がわからんのかわからん 原則としては例外ケースが生じない確信があろうとエラーコンテキストは引き継がれるべきで、 panicさせるのは当該ケースの対処のしようがないことがその場で明らかなケースのみ そして君のコード内でコントロールのしようがない事象である以上は基本的にそれは外部要因によるものだろうから、その要因を記載すればいい http://mevius.5ch.net/test/read.cgi/tech/1748392296/932
933: デフォルトの名無しさん [sage] 2025/06/20(金) 09:47:50.29 ID:Dy/CHU8X >>932 外部要因ならコード作者は制御できないんだからResultで表現すべきではない？ unwrapするケースって「このコードパスではxは（自分が書いたロジックが間違ってなければ）確実にSomeだから安全にunwrapできるはず」みたいなのだと思うんだけど、 その文をexpectに書いたとして誰が読むんだ？って疑問 http://mevius.5ch.net/test/read.cgi/tech/1748392296/933
934: デフォルトの名無しさん [sage] 2025/06/20(金) 10:32:17.84 ID:p4ugM+VW panic時のメッセージは未来の自分を含めて他の開発者向け ここの2つを読んでおくといいと思う https://burntsushi.net/unwrap/#why-not-use-expect-instead-of-unwrap https://www.thecodedmessage.com/posts/2022-07-14-programming-unwrap/ http://mevius.5ch.net/test/read.cgi/tech/1748392296/934
935: デフォルトの名無しさん [sage] 2025/06/20(金) 11:10:25.36 ID:Dy/CHU8X 開発者向けにコードの意図を説明するのって普通はコメントだと思うんだよね 例えばunsafeを使っても安全な理由とかもコメントで書くし なのにunwrapに限ってわざわざ文字列リテラルで書く理由が分からない（複数行や長文も書きづらいし） コメントとの違いは実行時に表示できることではあるけど 実行時にその一文を出せて嬉しいか？ 開発者なら結局周辺含めてコード読むんじゃない？ http://mevius.5ch.net/test/read.cgi/tech/1748392296/935
936: デフォルトの名無しさん [sage] 2025/06/20(金) 11:19:56.95 ID:FlGaOpZd 書いてて思ったけど「このメッセージが表示されたらライブラリのバグなんでこのGithubまで報告してね」 みたいなメッセージなら意味あるかな、という気がした エンドユーザーが見てちゃんと理解できるから実行時に出す意味もあるし、 ライブラリの内部エラーだからアプリケーション側には責任がないことも表明できるし http://mevius.5ch.net/test/read.cgi/tech/1748392296/936
937: デフォルトの名無しさん [sage] 2025/06/20(金) 11:25:39.91 ID:xog7LFS0 >>936 これいいな。OSSならそんな感じだしエンタープライズなら開発担当部門書いとこ http://mevius.5ch.net/test/read.cgi/tech/1748392296/937
938: デフォルトの名無しさん [sage] 2025/06/20(金) 12:33:04.85 ID:3ZKjcbd7 バグなんて他にもいくらでもあるんだから、それこそunwrapに限ってそんな懇切丁寧なケアをする理由がない やらかした犯人なんてgit blameですぐわかる http://mevius.5ch.net/test/read.cgi/tech/1748392296/938
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 64 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.031s