非同期通信のエラーハンドリングのあれこれ
シングルページアプリケーションを組んでいると、大量の非同期通信が必要になる。 そして、その非同期通信ごとにSuccess/Errorが存在する。
Successだけ対応していれば楽だけど、ユーザーのためにもエラーハンドリングは必須だ。
大きく分けてエラーは以下の3つ。
- 通信に失敗した(404含む)
- リクエストパラメータが間違っている
- 権限がない
それぞれどんなエラーを出すべきか。
通信に失敗した場合
だいたいサーバ側で何か不都合が起きている場合に発生する。
「○○に失敗しました。時間をおいて再度お試しください。」
あたりが妥当か？
このパターンは基本的にはサーバ側の問題が解決しないと復活しないので、ユーザーが何度試みようと失敗するものは失敗する。
しかし、ユーザーからすると自分の入力が悪いのか、はたまたシステムがバグっているのかの判断がつかない。
よってこのパターンでは、メッセージを出すより、システムエラー用のページにリダイレクトしてあげた方が親切かもしれない。
リクエストパラメータが間違っている場合
ユーザーが入力した要素に何らかの不備がある場合に発生する。
「○○を入力してください」
「○○は半角英数で入力してください」
「不正な文字が含まれています」
などを表示させてあげれば良い。
出来る限り、入力したいどの項目のどこが間違っていたのかを詳細に提示してあげた方が親切。
その分、バリデーションチェック側の手間もかかるけど。
権限がない場合
該当のAPIを叩く権限をユーザーが持っていない場合に発生する。
権限がないのであれば、そもそもボタンを押される前に防ぐべき。
画面側で権限をチェックして、ボタンをdisabledにするか、そもそも非表示にしておけばAPIを叩かれることはない。
画面経由以外で直接叩かれてしまった場合や、デベロッパーツールでdisabledを解除してクリックされた場合ももちろん想定しなくてはならない。
この場合は基本的にユーザーに悪意があるパターンが多いので、一律権限エラーページにリダイレクトさせてしまえば問題ないと思う。
画面内にエラー文言を表示するのかリダイレクトするのか問題
できれば画面内にエラー表示してあげたほうが親切であるとは思う。
特にPOST、PUT、DELETEにおいて、何らかのエラーがあったタイミングでエラーページにリダイレクトされたらイラっとするだろう。
GFTはどうだろうか？
何らかの事由により、データが取得できなかった時、 「データの取得に失敗しました。〈もう一度読み込む〉」 と表示するのが確かに親切かもしれない。
ただおそらくこのパターンは前節でも述べた通り、サーバ側の不具合である可能性が高い。
よって〈もう一度読み込む〉リンクを押下しても再び失敗する可能性が高い。
であれば、システムエラーのページにリダイレクトさせる方が親切だろう。
つまり、CRUD操作関係なしに、最初にあげた以下の3つのエラーに応じてハンドリングするのが良さそうだ。
- 通信に失敗した → リダイレクト
- リクエストパラメータが間違っている → 画面内にエラー表示
- 権限がない → リダイレクト
結局当たり前のような結論になってしまったが、色々自分の中で整理できたので良しとする。
