[過去ﾛｸﾞ] Rust part30 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
845: デフォルトの名無しさん [sage] 2025/06/17(火) 11:09:29.63 ID:QpxoSzQp(1) AAS
異常状態のまま動き続ける言語よりさ
panic or エラー処理されるRustが良い結論は変わらんよね
846(1): デフォルトの名無しさん [sage] 2025/06/17(火) 11:13:48.44 ID:wEWjoXoE(2/2) AAS
>>842
Google Cloud APIのコントロールプレーンのコアコンポーネントはさすがに一サービスの一コンポーネントとかいうレベルじゃないよ
OSのカーネルみたいなもん
こんなのヘタに誤動作を続けられたら会社が吹き飛ぶようなセキュリティ事故に繋がる可能性もあるわけで、死んでくれた方がマシ
847: デフォルトの名無しさん [sage] 2025/06/17(火) 11:52:15.15 ID:e/HQQ23L(1) AAS
ワンワンパニック
848(3): デフォルトの名無しさん [sage] 2025/06/17(火) 12:50:17.15 ID:ya3T3y3J(2/2) AAS
Javaで
if (value == null) {
throw AppException();
}
を書き忘れるのとRustで
let Some(value) = opt_value else { return Err(AppError); }
の代わりに
let value = opt_value.unwrap();
と書くのは発生リスクが全然違うと思うんだけど
Javaでうっかりnullチェックを忘れる人はRustでもうっかりunwrapを使うものなのか？
849: デフォルトの名無しさん [sage] 2025/06/17(火) 13:10:12.25 ID:aeCwWEdf(1) AAS
>>848
本人判断で「自明」と決めつけて意図的にunwrapを使うのでは
850: デフォルトの名無しさん [sage] 2025/06/17(火) 13:36:52.80 ID:gAVRJIie(1) AAS
>>822によれば
本人判断で「panicで落ちていい」と決めつけて意図的にunwrapを使うパターンもある
851: デフォルトの名無しさん [sage] 2025/06/17(火) 14:21:36.03 ID:w2F36Aoo(1) AAS
>>848
Rustでは必要により明示的にpanicさせる.unwrap()とコードを書いた時のみpanicが起きる
意思が必要
852: デフォルトの名無しさん [sage] 2025/06/17(火) 15:48:15.44 ID:FL91roa2(1/3) AAS
>>846
クラッシュしたのはコントロールプレーンの一部であるポリシーチェックシステムのさらにその一部のバイナリ
もっと言えば問題が起きたのはそのまた一部のクォータチェック部分
クォータチェックができなければGCPの全サービスを落とすべきというビジネス判断としてはなくはないがIncident Reportを見る限りGoogleはそうは考えてない
853: デフォルトの名無しさん [sage] 2025/06/17(火) 16:05:37.54 ID:UZ5mCAEQ(1) AAS
Rustにしとけ
続行不可能で意図的にpanicさせるか
きちんとResult/Option処理するかになる
854(1): デフォルトの名無しさん [sage] 2025/06/17(火) 16:27:46.74 ID:9ReeLirD(2/2) AAS
リリースしてから実際にポリシー変更が発生するまでの2週間、
テストやりこんで最後のバグだしするまでの時間とみなすか、
リリースヨシ！と思ってたかだよな
リリース後も2週間頑張ってテストやったけど境界条件探すの下手くそで見つけられませんでした、で通るかな。自分のことのようにゾッとする
855: デフォルトの名無しさん [sage] 2025/06/17(火) 17:05:59.65 ID:FL91roa2(2/3) AAS
>>854
プログラムの変更とポリシーデータの変更は責任者も管轄組織もプロセスも違うんだと思う
ポリシーデータのほうはビジネスよりの組織が管轄というのはよくある話
なのでDev的にはリリースヨシ！
改善点の2点目に「Regardless of the business need for 〜」とあるからOpsはBizの政治力で本来とは違うプロセスを強制させられたのかもしれない
856: デフォルトの名無しさん [sage] 2025/06/17(火) 18:12:51.30 ID:FL91roa2(3/3) AAS
ここに内部事情を含めていろいろ書いてあった
https://news.ycombinator.com/item?id=44274563
857(1): デフォルトの名無しさん [sage] 2025/06/18(水) 00:29:09.64 ID:1jrMASAC(1) AAS
ここでの議論と同じだね
Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ
858(1): デフォルトの名無しさん [sage] 2025/06/18(水) 01:06:16.44 ID:aQwOTYhv(1) AAS
>>857
>Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ
ここでもHNでもそんな議論はされてない
ただ複オジが連呼してるだけ
859: デフォルトの名無しさん [sage] 2025/06/18(水) 01:09:01.01 ID:ZwZRjmCs(1) AAS
さっさとC++捨ててRustにすれば防げたのにな
860(1): デフォルトの名無しさん [sage] 2025/06/18(水) 01:12:36.99 ID:SA0JPy/4(1) AAS
>>858
初心者は今回のこのまとめを見るといい
https://news.ycombinator.com/item?id=44281839
861: デフォルトの名無しさん [sage] 2025/06/18(水) 02:58:44.97 ID:vm71nNgD(1) AAS
Googleの事案なんてどうでもよくてインシデントにかこつけてRustの布教がしたいだけ
だから何を書いても無駄
862: デフォルトの名無しさん [sage] 2025/06/18(水) 06:20:38.83 ID:KrGEp9Dg(1) AAS
Rustを採用していれば防げた事案
863(1): デフォルトの名無しさん [sage] 2025/06/18(水) 09:57:10.50 ID:NQ+tIPxW(1/3) AAS
>>848
本質は同じ
書き忘れではなくロジカルな思い違いもある
ここでnulｌはないやろとここErrはないやろは同じで思い込みだから
言語によって優劣とかじゃなく人間の限界がある
864: デフォルトの名無しさん [sage] 2025/06/18(水) 10:09:02.91 ID:4yVSzLnj(1) AAS
>>863
全く違う
unwrap()はNone時にpanicを起こすための関数
書き忘れでpanicしない
865: デフォルトの名無しさん [sage] 2025/06/18(水) 10:20:51.18 ID:NQ+tIPxW(2/3) AAS
＞ 書き忘れではなくロジカルな思い違いもある
866: デフォルトの名無しさん [sage] 2025/06/18(水) 10:31:14.78 ID:GRTFL2K0(1) AAS
panicさせてはいけないプログラムでpanicさせる関数を呼ぶバカはいない
reviewでもバレる
867: デフォルトの名無しさん [sage] 2025/06/18(水) 10:49:25.62 ID:NQ+tIPxW(3/3) AAS
メモリリークさせてはいけないぷろぐらむでめもりりーくさせるばかはいない！
868: デフォルトの名無しさん [sage] 2025/06/18(水) 11:01:39.66 ID:Ulz+jHl5(1) AAS
Rustを使えばメモリリークも未定義動作もなく安全安心よ
869: デフォルトの名無しさん [sage] 2025/06/18(水) 11:23:14.90 ID:lQpFkqVW(1) AAS
haskellと比べて、unwrapが気軽に使えすぎる気はする
870: デフォルトの名無しさん [sage] 2025/06/18(水) 11:33:39.23 ID:S+5h0Q7c(1) AAS
ErrやNoneの時にpanic!を呼びたい場合が多いからunwrapがある
呼びたくないのに使うのは痴呆
871(1): デフォルトの名無しさん [sage] 2025/06/18(水) 11:34:34.48 ID:FuDCb+RV(1) AAS
index out of boundsやdivide by zeroをはじめ意図せずpanicを起こすケースなんていくらでもある
872: デフォルトの名無しさん [sage] 2025/06/18(水) 11:39:44.34 ID:SMOhWm6L(1) AAS
panicはcatchできるし
そのthreadが死ぬだけだし
困らんよな
873(1): デフォルトの名無しさん [sage] 2025/06/18(水) 11:43:26.69 ID:U/ksL7Wg(1) AAS
>>871
panic禁止のプログラムのためにpanicしない方法が用意されていますよ
勉強しましょう
874(1): デフォルトの名無しさん [sage] 2025/06/18(水) 11:45:58.97 ID:3o9Ti177(1/2) AAS
>>860
視野の狭い末端プログラマーの視点だな
システム全体が見えていない
875(1): デフォルトの名無しさん [sage] 2025/06/18(水) 11:46:56.90 ID:3o9Ti177(2/2) AAS
>>873
視野の狭い末端プログラマーの視点だな
システム全体が見えていない
876: デフォルトの名無しさん [sage] 2025/06/18(水) 11:50:22.96 ID:7xP0Uzu5(1) AAS
>>874
落ちてはいけないシステムをUB地雷だらけのC++で書くことが愚か
877: デフォルトの名無しさん [sage] 2025/06/18(水) 11:52:41.70 ID:qy96omZz(1) AAS
>>875
Rustのスレでシステム全体って何やねん
説明してみ
878(1): デフォルトの名無しさん [sage] 2025/06/18(水) 12:16:05.81 ID:iDJPvmxA(1) AAS
「意図したpanic」禁止したら良い
その「意図」が正しいのかコンパイラが静的分析出来ないから
879: デフォルトの名無しさん [sage] 2025/06/18(水) 12:29:52.79 ID:rx2CZFrG(1) AAS
>>878
panicはプログラムやスレッドが続行不可能な時に正しく終了させるためにあります
禁止は困ります
880: デフォルトの名無しさん [sage] 2025/06/18(水) 13:09:11.05 ID:uPLWgFQC(1) AAS
mseditorがpanicしたら編集中のデータが飛ぶけど、それが「正しく終了」か？
881: デフォルトの名無しさん [sage] 2025/06/18(水) 14:28:18.37 ID:AeXwuQQu(1) AAS
ヌルポやバッファオーバーランに比べれば比較的マシ
882: デフォルトの名無しさん [sage] 2025/06/18(水) 15:01:02.42 ID:90mEbGf5(1) AAS
意図的ヌルポでセグフォと
意図的unwrap panicでabortは同じ
883: デフォルトの名無しさん [sage] 2025/06/18(水) 15:13:41.28 ID:5Mu65nKv(1) AAS
会社の怖い先輩が俺のコードはunwrapでいいんだよと言ったら、そうするしかないよね
884(1): デフォルトの名無しさん [sage] 2025/06/18(水) 15:24:13.90 ID:45cvT+VF(1) AAS
まさかとは思うがnullチェックしてれば防げた障害だと思ってるやつがいるのか？
885: デフォルトの名無しさん [sage] 2025/06/18(水) 15:37:47.95 ID:s5c+Ng5v(1/2) AAS
ぬるぽでクラッシュしたと聞いたけどnullチェックで防げないぬるぽってあるんすか
886: デフォルトの名無しさん [sage] 2025/06/18(水) 15:49:01.71 ID:FHNv6txf(1) AAS
今どきC++で新たなコードを書くから悲惨な事故が起きた
887: デフォルトの名無しさん [sage] 2025/06/18(水) 16:01:28.34 ID:hZyAyOg0(1) AAS
>>884
Rustなら防げたと言ってるあのおじさんを除けばそこまてのバカはいないかと
888: デフォルトの名無しさん [sage] 2025/06/18(水) 16:01:44.34 ID:s5c+Ng5v(2/2) AAS
設定がおかしい場合の例外処理フローはあったけどそこに入る前にぬるぽで爆死した認識
889: デフォルトの名無しさん [sage] 2025/06/18(水) 16:35:49.37 ID:YaS/uO3Z(1) AAS
RustならコンパイラがAIよりも厳密なチェックをしてるから防げるだろ
890: デフォルトの名無しさん [sage] 2025/06/18(水) 17:03:37.08 ID:d8qsI0SX(1) AAS
Rustは言語仕様が優れているけど
言語仕様が腐っていればAIでも防げない
891: デフォルトの名無しさん [] 2025/06/18(水) 17:43:59.13 ID:mspDq+p2(1) AAS
世界最長のコンテキストウィンドウ100万トークン入力・8万トークン出力対応にもかかわらずたった7800万円でトレーニングされたAIモデル「MiniMax-M1」がオープンソースで公開され誰でもダウンロード可能に
2025年06月18日 11時43分
https://gigazine.net/news/20250618-minimax-m1-open-source/
>>MiniMax-M1は、合計4560億のパラメーターが含まれており、トークンごとに459億のパラメーターがアクティブになるとのこと。これはDeepSeek R1の8倍に相当するコンテキストウィンドウです
>>以下のグラフは競技レベルの数学、コーディング、ソフトウェアエンジニアリング、エージェントツールの使用、長文理解タスクにおけるパフォーマンスを主要な商用AIモデルと比較したもの。赤色がMiniMax-M1で、どのタスクにおいても競合AIモデルに匹敵するパフォーマンスを発揮できている
>>MiiniMax-M1はいくつかのベンチマーク、特に長いコンテキスト駆動のベンチマークでClaude Opus 4のパフォーマンスを上回りました」と報告
※AIを動作させている動画あり
↓上記のAIお下記をプレイさせれば性能が判明する
Gemini 2.5 Proは手持ちのポケモンが瀕死になるとパニックに陥る
2025年06月18日 12時30分
https://gigazine.net/news/20250618-pokemon-gemini-panic/
◇
[プロテクトガードやセキュリティーホール発見可能]
※1 プログラムのバグ技[裏抜け道]を使用できる＝チートコードを発見可能
・ マリオカートのショートカットはプレイヤー「極悪人」の表の抜け道でNPC「一般人」は使用不可能
[インサイダー/談合/なねーロンダリング/霊感商法など行う時の悪行で音波や電波をしての悪行の方法を発見可能
※ 政治家の法律上の抜け道を仕込める＝ある業種だけの法律の抜け道を発見可能
[一般大衆の思考である特定の極悪人から目線を特定の統合失調症へ返させる装置]
※ ＡＩは正確な情報で人間を信用させれる＝ＡＩは嘘の情報を一部混ぜて人間を洗脳できる
892: デフォルトの名無しさん [sage] 2025/06/18(水) 18:45:36.06 ID:JUQ8VjRJ(1) AAS
まさかとは思ってたがnullチェックで防げたと勘違いしてるやつ結構いるんだな
893: デフォルトの名無しさん [sage] 2025/06/18(水) 19:12:39.40 ID:M/E4rLLd(1) AAS
＞読み込みデータに空白フィールドがあり、これがヌルポインタとなって参照した時点でクラッシュを引き起こした。
894(2): デフォルトの名無しさん [sage] 2025/06/18(水) 20:36:14.97 ID:QsB71xf7(1) AAS
OptionやResultの型をきっかけとして問題に気付けた可能性はあるんじゃない？
あくまで間接的な可能性でしかなく、この件をもってRustだったら起きなかったとかいうのはアホ丸出しだけども
895: デフォルトの名無しさん [sage] 2025/06/18(水) 20:49:33.05 ID:JDJPNF+q(1) AAS
Rustなら上位へそのエラー返して
その入力データに対するAPIでエラー返すだけだろ
896: デフォルトの名無しさん [sage] 2025/06/18(水) 22:27:10.05 ID:/Y6EEbbi(1) AAS
>>894
いいかげんにしろよ
Rustでどうやって問題が起きるんだよ
897(2): デフォルトの名無しさん [sage] 2025/06/18(水) 22:47:29.81 ID:BBnSRnVn(1) AAS
この件については、クラッシュを回避しエラーレスポンスを返したところで結局障害になることには違いがないからだな
898: デフォルトの名無しさん [sage] 2025/06/18(水) 22:51:57.91 ID:ikP0pQuf(1) AAS
>>894
間接的な可能性もないでしょ
899(1): デフォルトの名無しさん [sage] 2025/06/18(水) 23:03:07.16 ID:0KvtUriT(1) AAS
>>897
Googleのレポート見ろよ
エラーを返せていれば障害にならなかった
900: デフォルトの名無しさん [sage] 2025/06/18(水) 23:18:21.28 ID:dYsLBH+C(1) AAS
>>899
そんなことどこにも書いてないぞ
エラーを返していればなんで障害にならないんだ？
回復不能なエラーだぞ
901: デフォルトの名無しさん [sage] 2025/06/18(水) 23:25:54.18 ID:7PLt8980(1) AAS
Rustなら回避できたケースだけど
無理！と言う人は具体的に無理なシナリオを示してみたら？
902: デフォルトの名無しさん [sage] 2025/06/18(水) 23:41:41.61 ID:sPCFWro/(1) AAS
ワロ
理解できないから教えてくれと言えばいいものを
903: デフォルトの名無しさん [sage] 2025/06/18(水) 23:53:20.04 ID:jD4yZQcZ(1) AAS
公式読めよ
Rustにしてればポリシー変更データをエラーにして受け付けず落ちることもなく被害なし
904(1): デフォルトの名無しさん [sage] 2025/06/19(木) 00:10:11.24 ID:oQzIUk1I(1) AAS
設定のミスで１台のATMが使えなくなるか全部のATMが使えなくなるかみたいな話でしょ
どっちも障害だから同じだって考え方もあれば
障害を１台に抑えることに価値があるって考え方もある
Rustでも防げないって人は前者だしRustなら防げたって人は後者
どっちの考え方もそれなりに正しい
905(1): デフォルトの名無しさん [sage] 2025/06/19(木) 00:25:10.66 ID:KZlMfI+O(1) AAS
>>897
exponential backoffが実装されてなかったから
リクエスト単位のエラー返しにしてた場合は
復旧にもっと時間がかかってたと思われる
かといってC++でヌルポはだめだけどな
906(2): デフォルトの名無しさん [sage] 2025/06/19(木) 00:48:27.34 ID:ftBjTcDx(1) AAS
>>905
新たなポリシー変更要求がエラーで受け付けられなくて落ちることもないから障害が起きていない
907(1): デフォルトの名無しさん [sage] 2025/06/19(木) 01:27:03.00 ID:l2wwX0Hv(1/2) AAS
>>906
どこにそんなこと書いてる？
新しいポリシーがSpannerに書かれてレプリケートされた後の話だろこれ
908(1): 907 [sage] 2025/06/19(木) 01:37:22.30 ID:l2wwX0Hv(2/2) AAS
ああ、もしかしてポリシーのチェックというのをポリシー自体のバリデーションと勘違いしてるのかな
正しくはポリシーに基づいてAPIリクエストをチェックする処理のことなんで、新しいポリシーが反映された結果としての障害だよ
909: デフォルトの名無しさん [sage] 2025/06/19(木) 01:38:01.02 ID:QXnAvsJc(1) AAS
>>904,906
君は何を言ってるんだい？
Googleのレポート見ろよ&&公式読めよブーメランが刺さってるぞ
910: デフォルトの名無しさん [sage] 2025/06/19(木) 02:14:01.17 ID:Pd2QOZgo(1) AAS
>>908
新しいポリシーを反映させないか
反映させても空白のみエラーで飛ばせば障害は起きていない
911: デフォルトの名無しさん [sage] 2025/06/19(木) 04:21:35.41 ID:yro0K3vV(1) AAS
Rustにしとけってことか、速い話が
912: デフォルトの名無しさん [sage] 2025/06/19(木) 05:04:25.47 ID:ct5m24p0(1) AAS
落ちるプログラムを各リージョンにバラ撒かなければ何製でも防げてる
もちろんRustなら確実に防げた
913: デフォルトの名無しさん [sage] 2025/06/19(木) 06:59:17.36 ID:tFafecL1(1) AAS
とにかくRustにすれば安心安全
これはもう常識
914: デフォルトの名無しさん [sage] 2025/06/19(木) 11:59:43.17 ID:cYRDzc4D(1) AAS
ちゃんとした人が、Rustを使った場合に限る。
セキュリティもそうだけど、人が関わると碌なことがない。
915: デフォルトの名無しさん [sage] 2025/06/19(木) 12:27:53.31 ID:/pQfT2SX(1) AAS
Rustは安全に配慮したコンセプトはいいけど、それを徹底できていない。
せめてSafe Rust強制モードとpanic禁止モードは用意しておくべきだった。
916: デフォルトの名無しさん [sage] 2025/06/19(木) 21:29:19.19 ID:67nyX+fT(1/3) AAS
CPUとメモリは自由なunsafeが本質なので下位のライブラリは標準もデファクトもunsafeで作られている
917: デフォルトの名無しさん [sage] 2025/06/19(木) 21:38:06.06 ID:67nyX+fT(2/3) AAS
panicは意図せず混入防止も兼ねてこんな運用が多いかな
[lints.clippy]
missing_panics_doc = "warn"
918: デフォルトの名無しさん [sage] 2025/06/19(木) 21:49:11.90 ID:nNn4PbNI(1/2) AAS
標準ライブラリが内部では unsafe だらけというのは確かにそう。
外側に対しては安全になるように配慮してるけど、バグが絶対にゼロかというとそんなことはないし、実際に発見されたこともある。
まあ unsafe に限らず処理系や標準ライブラリにバグがあることを疑ってたらきりがないからそこらは割り切らないと仕方なくない？
919(1): デフォルトの名無しさん [sage] 2025/06/19(木) 21:56:40.37 ID:6vmjzLKI(1) AAS
みんな律儀にResultは全てちゃんとハンドリングしてるの？
Mutex.lock() なんかは気にせず unwrap してるんだけど
920: デフォルトの名無しさん [sage] 2025/06/19(木) 22:11:01.42 ID:nNn4PbNI(2/2) AAS
>>919
ロックが失敗するのはスレッドがパニックしたとき。
つまりハンドリングするならそのスレッド内のエラーであるべきで、 Mutex.lock の失敗に対してハンドリングしても出来ることがない。
そこは普通は unwrap してよいところだと思う。
921: デフォルトの名無しさん [sage] 2025/06/19(木) 23:34:30.87 ID:67nyX+fT(3/3) AAS
そのmutex毒入り状態からの復帰処理をしたい場合はunwrapせずにErr時に処理とclear_poison()する
922(1): デフォルトの名無しさん [sage] 2025/06/20(金) 00:31:53.70 ID:xog7LFS0(1/5) AAS
これおもしろー
https://blog.guillaume-gomez.fr/articles/2025-06-19+Rust%3A+Optimizing+integer+to+string+conversions
ポインターアクセスより配列の方が速いんやー
923(1): デフォルトの名無しさん [] 2025/06/20(金) 01:02:39.89 ID:SpbybkFq(1) AAS
unwrapではなくexpectを使う。
924(1): デフォルトの名無しさん [sage] 2025/06/20(金) 01:08:46.49 ID:xog7LFS0(2/5) AAS
>>923
いや、Optionにはunwrap使ってええんやで
コードに合わせて柔軟に対応すりゃバグは防げるよ
ビジネスロジックのバグは入念なテストしないと見つけられないけどね
ビジネスロジックのバグでシステム障害になることもまあ、あるっちゃあるよねテストしてなきゃ
925: デフォルトの名無しさん [sage] 2025/06/20(金) 01:13:11.37 ID:/9Nz/yYP(1/2) AAS
>>922
昔読んだが00～99のテーブルをコピーするところだな
配列境界検査は起きないコードだから速度は同じ
926: デフォルトの名無しさん [sage] 2025/06/20(金) 01:18:17.09 ID:/9Nz/yYP(2/2) AAS
>>924
panic許容シーンでない場合
絶対Some保証できない場ではunwrapもexpectも使わないよな
927(1): デフォルトの名無しさん [sage] 2025/06/20(金) 07:50:16.10 ID:d5bZ3vB1(1/2) AAS
expectに書く文がいまいち分からんのだよな
エンドユーザーがその一文だけ見て何か意味があるとも思えないし
デバッグする開発者向けなら結局前後の文脈込みで見るしかないから
unwrapにして詳細をコメントに書いたほうがいい気がしている
928(1): デフォルトの名無しさん [sage] 2025/06/20(金) 08:04:54.66 ID:Op1qS17W(1) AAS
>>927
ユーザに文章を示してpanicさせたいの？
文章をprintかeprintしてからpanic!呼んだら？
929(1): デフォルトの名無しさん [sage] 2025/06/20(金) 08:15:40.44 ID:d5bZ3vB1(2/2) AAS
>>928
いや、そうじゃなくて「unwrapの代わりにexpectを使ってunwrapしても大丈夫な理由を明記すべき」みたいな言説があるじゃん？
そのときにexpectに書くべき文がわからんって話
ユーザ向けにエラーとして表示したいならそりゃ普通にResult使うし、
どうしてもパニックしたいならprintlnすればいいのはその通りだけど
930: デフォルトの名無しさん [sage] 2025/06/20(金) 08:22:37.63 ID:xog7LFS0(3/5) AAS
基本フロントエンド側とAPIのエラーコード、エラーメッセ仕様は最初に決めておくから、あとは「どの関数レイヤーで」そのIFに合わせこむかだけじゃない？
ここのスレ多分Rustを業務用で使ってる人ばっかだから仕様の取り決めとから雇用主から降ってくるもんだと思うけど。返すエラー定義決まってなきゃそもそもテストコード先に書けないし、納品物にもテスト結果入れれなくて困るしな
931: デフォルトの名無しさん [sage] 2025/06/20(金) 08:25:55.42 ID:xog7LFS0(4/5) AAS
個人的にはtracing::debug!で自分用のデバッグ出力はON/OFFしてるけど、エラーコードやエラーメッセージは案件別に全然仕様が違うwwwやめてwwwから、仕方なくErrで一旦上げてresponse.bodyに詰め込む直前で相手さんの期待する結果になるようにparseしてることが多い
フロントエンド側で翻訳ぐらいせえやーって思うけど、たまにバックエンドで各言語に合わせて翻訳やってくれー案件もあったりするしバラバラで何考えてんのかはよー分からん
932(1): デフォルトの名無しさん [sage] 2025/06/20(金) 09:04:21.71 ID:ymNSNGAk(1) AAS
>>929
https://doc.rust-lang.org/std/error/index.html#common-message-styles
に尽きると思うが、何がわからんのかわからん
原則としては例外ケースが生じない確信があろうとエラーコンテキストは引き継がれるべきで、
panicさせるのは当該ケースの対処のしようがないことがその場で明らかなケースのみ
そして君のコード内でコントロールのしようがない事象である以上は基本的にそれは外部要因によるものだろうから、その要因を記載すればいい
933: デフォルトの名無しさん [sage] 2025/06/20(金) 09:47:50.29 ID:Dy/CHU8X(1/2) AAS
>>932
外部要因ならコード作者は制御できないんだからResultで表現すべきではない？
unwrapするケースって「このコードパスではxは（自分が書いたロジックが間違ってなければ）確実にSomeだから安全にunwrapできるはず」みたいなのだと思うんだけど、
その文をexpectに書いたとして誰が読むんだ？って疑問
934: デフォルトの名無しさん [sage] 2025/06/20(金) 10:32:17.84 ID:p4ugM+VW(1) AAS
panic時のメッセージは未来の自分を含めて他の開発者向け
ここの2つを読んでおくといいと思う
https://burntsushi.net/unwrap/#why-not-use-expect-instead-of-unwrap
https://www.thecodedmessage.com/posts/2022-07-14-programming-unwrap/
935: デフォルトの名無しさん [sage] 2025/06/20(金) 11:10:25.36 ID:Dy/CHU8X(2/2) AAS
開発者向けにコードの意図を説明するのって普通はコメントだと思うんだよね
例えばunsafeを使っても安全な理由とかもコメントで書くし
なのにunwrapに限ってわざわざ文字列リテラルで書く理由が分からない（複数行や長文も書きづらいし）
コメントとの違いは実行時に表示できることではあるけど
実行時にその一文を出せて嬉しいか？
開発者なら結局周辺含めてコード読むんじゃない？
936(2): デフォルトの名無しさん [sage] 2025/06/20(金) 11:19:56.95 ID:FlGaOpZd(1) AAS
書いてて思ったけど「このメッセージが表示されたらライブラリのバグなんでこのGithubまで報告してね」
みたいなメッセージなら意味あるかな、という気がした
エンドユーザーが見てちゃんと理解できるから実行時に出す意味もあるし、
ライブラリの内部エラーだからアプリケーション側には責任がないことも表明できるし
937: デフォルトの名無しさん [sage] 2025/06/20(金) 11:25:39.91 ID:xog7LFS0(5/5) AAS
>>936
これいいな。OSSならそんな感じだしエンタープライズなら開発担当部門書いとこ
938: デフォルトの名無しさん [sage] 2025/06/20(金) 12:33:04.85 ID:3ZKjcbd7(1) AAS
バグなんて他にもいくらでもあるんだから、それこそunwrapに限ってそんな懇切丁寧なケアをする理由がない
やらかした犯人なんてgit blameですぐわかる
939(1): デフォルトの名無しさん [sage] 2025/06/20(金) 13:09:09.82 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");
// ...
}
940: デフォルトの名無しさん [sage] 2025/06/20(金) 15:04:20.99 ID:3ZuChe0s(1/2) AAS
>>939
基本的にはその考え方で正しい。
でも標準ライブラリや処理系すらそうしてないし、現実は理想通りではない。
941(1): デフォルトの名無しさん [] 2025/06/20(金) 16:00:22.03 ID:r2H2v8it(1) AAS
Haskellにはならなかったな
Rustにもならないのでは？
942: デフォルトの名無しさん [sage] 2025/06/20(金) 16:21:36.04 ID:+wQsfMK/(1) AAS
>>941
Rustは本来的にはコーディングの誤りに対して939のようにわりと問答無用でpanicする指向だと思うけど、
関数型というかHaskellかぶれのオモチャにされてるせいで実行時panicダサいみたいな空気が醸成されてきている一方で、
なんでも型のコンテキストで上手に扱えるほど型に表現力があるわけでもないから中途半端な感じになってるね
943: デフォルトの名無しさん [sage] 2025/06/20(金) 16:41:57.96 ID:3ZuChe0s(2/2) AAS
システムプログラミング言語としての性質があるから仕方がない面はある。
ハードウェアやら OS やらが Rust の性質に従ってくれるとは限らないので言語の側で合わせないと仕方がない。
944: デフォルトの名無しさん [sage] 2025/06/20(金) 16:53:23.26 ID:IXOAfd5T(1) AAS
Rustバランスいいよな
抽象度の高い記述ができつつC言語の代替もできる
上下前次1-新書関写板覧索設栞歴
あと 58 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s