25/11/20 21:24:39.80 W1oxwi29.net
>>756
Again, the limit exists because for performance reasons we preallocate memory for the features.
だから、コーダーでもコントロール可能な範囲じゃない？
こんなんじゃリーナスじゃなくてもpanic禁止言いたくなるわな。
758:デフォルトの名無しさん
25/11/20 21:39:21.39 lwx9Ifqo.net
>>754
パニックさせるのが正解などというバカのことを言ってるのは複オジ一人だけじゃん
自分の意見を複製してもなりすまし書き込みしてもみんなが言ってることにはならないよ
759:デフォルトの名無しさん
25/11/20 21:50:20.55 H4pjbMpd.net
これは普通にpanicで正解でしょ
メモリを固定ではなくfeatureファイルに合わせて動的アロケーションするようにしていれば即障害にはならなかっただろうけど、
それはunwrapの是非とかの次元の話じゃないし、複おじの頭はそこまで回らないだろう
760:デフォルトの名無しさん
25/11/20 21:50:58.54 ao6/JbGK.net
続行不可能なのだからどこかで必ずpanicすることになる
C言語ならexit(non-0)
Rustはもっと賢いpanicがありそれを使う
他に手はない
761:デフォルトの名無しさん
25/11/20 21:56:43.11 uDj2zLmM.net
続行可能なら上位へエラーを返せばいいんだよね
続行不可能なら上位へエラーを返すより即panicさせるのが正しいよ
その方がバックトレース的にも有利
762:デフォルトの名無しさん
25/11/20 22:04:24.95 A4EEH+q2.net
続行可能／不可能はコーダーが判断することではないよ。ふつうにエラーを返せ。
763:デフォルトの名無しさん
25/11/20 22:09:40.31 uDj2zLmM.net
>>762
続行不可能なのにエラーを返してどうするの？
そこでpanicさせるしかないよ
764:デフォルトの名無しさん
25/11/20 22:18:59.74 H4pjbMpd.net
>>762
起動時に必要なデータなんだろうから、エラー返したところで上位でもどうしようもないでしょ
仮にエラーを無視してそのまま起動させたとして、不正な状態だからってリクエストを5xxで落とすのはまずいのはさすがに分かるよな?
Bot Managementというのがどれだけ重要なのかは知らないけど、
最悪それが機能してなくてもいいならエラー無視してそのモジュールの処理だけ飛ばすのは結果論としてはアリだったかも
でもそれ言い出したら極論何でもかんでもフェールソフトにしなきゃいけないから、それこそゆるふわ設計になりすぎてRustのメリットが薄れちゃうよ
765:デフォルトの名無しさん
25/11/20 23:12:52.86 eUKDlPgK.net
もっと簡単にエラー科研のこやつは
766:デフォルトの名無しさん
25/11/20 23:13:07.19 eUKDlPgK.net
アプデで改善しーやー
767:デフォルトの名無しさん
25/11/20 23:13:24.18 eUKDlPgK.net
もう普通にtry catchでええ
768:デフォルトの名無しさん
25/11/20 23:13:43.88 c/hk2jJw.net
Rustのプログラム開発デバッグそして運用実行時の問題発生で最も役立つ仕組みがpanicなのにそれを理解しないでpanicを毛嫌いしてる人がいる不思議～
769:デフォルトの名無しさん
25/11/20 23:38:50.21 bMsqNQja.net
>Rustのプログラム開発デバッグそして運用実行時の問題発生で最も役立つ仕組み
具体的になんの開発時にそう感じたの？
770:デフォルトの名無しさん
25/11/21 02:04:51.36 iIZE15hu.net
>>764
>起動時に必要なデータなんだろうから
そーなん？どこ情報？
771:デフォルトの名無しさん
25/11/21 02:19:37.89 bQYXRKni.net
>>764
公式は以下があるべき姿と見ているようだが
>Remediation and follow-up steps
>Remediation and follow-up steps
>Now that our systems are back online and functioning normally, work has already begun on how we will harden them against failures like this in the future. In particular we are（今後同様の障害が発生した場合に備え、以下を重点とするシステムを強化する取り組みに着手）:
> - Hardening ingestion of Cloudflare-generated configuration files in the same way we would for user-generated input（内部生成データも外部入力と同じレベルで検証）
> - Enabling more global kill switches for features（特定の機能を無効化する仕組みに拡大、例：「ボット管理構成を正常だったバージョンにロールバック」「ボット管理システムの停止」）
> - Eliminating the ability for core dumps or other error reports to overwhelm system resources（コアダンプやエラーレポートによって圧迫されるのを防ぐ、システム、アプリケーションでの制御）
> - Reviewing failure modes for error conditions across all core proxy modules（エラー状態の障害モードを見直す）
>An outage like today is unacceptable. We've architected our systems to be highly resilient to failure to ensure traffic will always continue to flow. When we've had outages in the past it's always led to us building new, more resilient systems.（今回のような障害は容認できない、耐障害性の高い新しいシステムを構築するきっかけとなった）
URLﾘﾝｸ(blog.cloudflare.com)
>>768
そんなのサービス要件、用途、場面次第では
そもそもエラーの可能性を含意するResultを返していることを意にも介さず、ハンドリングしないのは言語の思想にもとるかと
パニックの好悪ではなく、サービス要件、場面に対してミスマッチだと指摘されているのでは
772:デフォルトの名無しさん
25/11/21 02:41:53.57 7QFg1F5C.net
panic禁止派がいるからでしょ
結局プログラムを終了させるなら深いところでpanicさせることでバックトレース情報を最大化しましょう
773:デフォルトの名無しさん
25/11/21 03:02:34.17 aQgyxReD.net
panic禁止派って、正常な関数だと辿りつかない状態になったらどうすんの？
anyhowとかでthis is bugとかって返すの？
774:デフォルトの名無しさん
25/11/21 03:12:36.25 BgHvS9/N.net
それを議論して何か自分のためになることがあると思うの？
775:デフォルトの名無しさん
25/11/21 03:19:36.71 szwMnzU9.net
てかたまに思うんだけどエラー処理てif文でよくね？
776:デフォルトの名無しさん
25/11/21 04:06:05.39 bmEBh7Lw.net
>>771
Resultが返ってきた時にpanicさせることは立派なハンドリングだよ
例えば読み込み必須なデータファイルがopenできずにErrを返しプログラムが続行できないからpanicなど
777:デフォルトの名無しさん
25/11/21 06:09:46.10 pxhgH2KX.net
日本語翻訳があるんだから、少しは元記事に目を通せや。
URLﾘﾝｸ(blog.cloudflare.com)
cloudflareはエラーハンドリングに失敗して原因追求できずに大規模DDoS攻撃と誤認したんだろ。
このケースでpanicが正しかったとはとても思えない。