最も高価なのはバグではなく、エラーメッセージが原因で調査方向を誤らせることです。
当社のバックエンドで2日間にわたり「サーバーからのデータ読み取り不可」のアラートが発生していたが、サーバー側を徹底調査したところ、ログにはすべて200ステータスのみ記録されていた。真の原因は、ブラウザで実行中の古いスクリプトが新しいデータをレンダリングする際にクラッシュしており、 catch すべての例外を「サーバーからのデータ読み取り不可」として集約していたことにある。このツールは2つのことを実行する：まず、既存の catch 句を貼り付けて、それが故障を誤報告していないかを検証；次に、「区別可能な」ネットワーク失敗 / レンダリングクラッシュ / 密钥失效 / タイムアウトのコード。
—
| 実際の状況 | 報告すべきエラー | エラー報告のコスト |
|---|---|---|
| ネットワーク／接続失敗 | ネットワークが不安定です。N 回再試行しました。まずローカルキャッシュを表示します。 | サーバー障害として報告 → サーバー側を無駄に調査することになります。 |
| データは到着しましたが、レンダリングがクラッシュしました | スクリプトのバージョンが古くなっています。Ctrl+F5 で強制再読み込みしてください。 | サーバー障害と誤って報告 → 方向が2日間ずれました |
| 401 / 403 | キーが無効です。ページを更新して再ログインしてください。 | ユーザーに「再試行」を繰り返しクリックさせても、問題は決して解決しません。 |
| タイムアウト（AbortError） | インターフェースがタイムアウトしました。しばらく待ってから更新ボタンをクリックして再試行してください | 「サーバーがダウンした」と混同されています |
| データ形式が空 / フィールドが欠落しています | データは到着済みですが、フィールド X が不足しています | エラーを出さずに0にレンダリングされる方が、エラーを報告するよりも危険です。 |
1・1つのcatchで全てのエラーを報告しています。レンダリングクラッシュ、ネットワーク失敗、キーの無効化、タイムアウトはすべて「サーバーからのデータ読み取り不可」として集約され、2日間もサーバー上で存在しない問題を探し続けていた。
2・修正方法はトラフィックを分散させることであり、ログを追加することではありません。try ここにはデータ取得のみを記述し、レンダリングは別途1層ラップします try「，」で区切って2文に分けてエラーを報告してください——調査方向は1文で即座に特定できます。
3・エラー報告よりもフォールバックが重要です。完全な失敗時には localStorage に保存された前回の正常なデータでレンダリングし、「キャッシュデータ · N 分前」と表示する。ユーザーは常に何かが表示される状態になり、エラー画面の壁に直面することはない。
4・401/403エラーでは再試行しないでください。APIキーが間違っている場合、3回再試行してもユーザーが数秒余分に待つだけです。代わりに、リフレッシュして再ログインするよう直接通知してください