6ヶ月間、エラーを握りつぶしていた
エラーハンドリングは上手くいっていると思っていた。
try/catchブロックを使い、コンソールにログを出し、Sentryのダッシュボードも使っていた。
それでも、ユーザーは壊れたフローに直面していた。ファイルは消え、決済は確認なしに進み、フォームは音もなく失敗した。
問題はエラーをキャッチできなかったことではない。エラーをキャッチした上で、何もしていなかったことだ。
コードにはこんなコメントがあった： // TODO: handle this better
そのコメントは6ヶ月間、そのまま放置されていた。
アップロードが失敗しても、ユーザーには止まらないローディングスピナーが表示されるだけだった。何かが起きたことすら分からず、何度もやり直し、そして諦めてしまった。
顧客からの苦情を受けてアナリティクスを確認したところ、次のような数字が出てきた。
• ファイルアップロードの23%がサイレントに失敗していた。 • ユーザーは平均2.7回リトライを試みていた。 • すべてのエラーをキャッチしていたため、ダッシュボードは「正常」を示していた。
私たちは「静かなる災厄」を運営していた。ダッシュボードは緑色だったが、ユーザーはフラストレーションを溜めていた。
すべてのサイレントなキャッチを新しいパターンに置き換えた。現在はエラーをタイプ別に分類している。
• ネットワークエラーはリトライダイアログを表示する。 • 権限エラーはガイドを表示する。 • 不明なエラーは明確なメッセージを表示し、コンテキストをログに記録する。
その結果、すべてが変わった。
• サイレントなアップロード失敗は23%から0.4%に減少した。 • ユーザーからのアップロードに関する報告は89%減少した。 • ファイル紛失に関するサポートチケットは、週15件から週1件に減少した。
最大の成果は可視化だ。チームは即座に失敗を把握できるようになった。怒りのメールを待つ必要はなくなった。
エラーハンドリングとは、クラッシュを防ぐことではない。失敗をユーザーとチームの両方に可視化することだ。
クラッシュは正直だ。サイレントな失敗は嘘だ。
catchブロックを書くときは、自分自身に2つの質問を投げかけてほしい。
- これが失敗したとき、誰が知る必要があるか？
- 彼らは次に何をすべきか？
もし答えが「誰もいない」なら、それは問題だ。
Optional learning community: https://t.me/GyaanSetuAi