[過去ﾛｸﾞ] Rust part30 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
823(4): デフォルトの名無しさん [sage] 2025/06/16(月) 18:48:18.73 ID:Y40wNqxo(2/2) AAS
>>822
後者に該当
ポリシーデータから必須項目が欠落しているような状態はヌルポを発生させたプログラマーから見ればプログラムを即停止すべき異常事態という認識
825: デフォルトの名無しさん [sage] 2025/06/16(月) 19:03:13.08 ID:WftbHuxu(1/2) AAS
>>823
異常時に停止してよい時のみpanicが使われて暴走やセキュリティの穴を防止するんだよ
827(1): デフォルトの名無しさん [sage] 2025/06/16(月) 19:45:53.03 ID:GmbZlZxT(2/2) AAS
>>823
panicにするかどうかを決めるのはサーバーを実装する側じゃなくてサーバーを使うユーザー側だろ。
Linusじゃないけど、サーバー側がランタイムエラーでパニックを発生させるのは根本的に問題がある。単にエラーを返すべき。
832(1): デフォルトの名無しさん [sage] 2025/06/17(火) 07:28:54.01 ID:nAKE0zH5(1) AAS
>>829
ならpanicさせる>823の考えは間違いだね。
rustも安全性を標榜するならpanic禁止モードを用意すべきだわ。
842(2): デフォルトの名無しさん [sage] 2025/06/17(火) 10:51:31.79 ID:gnbFtFWo(1) AAS
>>832
ヌルポでクラッシュさせてたのは間違いではなかったとでも？
>>823はヌルポでクラッシュさせてた人たちの認識
その人たちが仮にRustを使ってたら同じようにpanicで落とすだけ
つまりRustを使っていたとしても障害は防げないという話
それに今回の障害を見てエラーハンドリングしていれば問題なかったと考えるのは短絡的すぎる
一番の問題点は一サービスの一コンポーネントがクラッシュしただけであらゆるサービスが全面的にダウンしたという点にある
だからあらゆるコンポーネントを絶対panicしないように作ろうとするよりも一コンポーネントがpanicしたとしても全面的なシステムダウンに繋がらない仕組みを作ろうと考えることが今回のような障害を防ぐための第一歩
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.056s