📌 エラーメッセージ処理の完全ガイド：なぜ複数fallbackを使うのか？
エラーメッセージを画面に表示するとき、次のようなコードをよく見かけます：
showError(
result.error || res.statusText || "Googleログインに失敗しました。"
);
このように「3つの候補を順に確認する」書き方は、ただの冗長ではなく、実際の開発・運用で起こり得る“曖昧なエラー応答”にしっかり対応するテクニックです。
✅ 書き方解説（優先順に確認する3つの候補）
1. result.error
- サーバー側（Fastifyなど）で
reply.send({ error: "メッセージ" })として明示的に返されたエラー文 - 自分で定義したエラー内容なので、最も具体的でユーザーにとって有用
2. res.statusText
- HTTPステータスコードに対応するテキスト（例："Unauthorized", "Internal Server Error"）
-
result.errorが空、またはJSONではなくtext/plainで返されたときの保険になる - ブラウザが自動的にセットするテキストなので最低限の情報は担保される
3. "Googleログインに失敗しました。"
- どちらの情報も無かった場合の“最後の砦”
- 完全に壊れたレスポンス（例：ネットワーク断、サーバーダウンなど）でも何かを表示することで「無反応状態」を避けられる
🧠 なぜこの書き方が重要なのか？
- エラー時にユーザーが何も見えないのが最悪（"反応がない" = 離脱要因）
- バグ・API障害・意図しない空レスポンスなど、予期しない状況は現場で必ず起きる
- そのすべてに備えて、可能な限り有用な情報を順に拾う仕組みが必要
✅ 最小構成でも良い？
場合によっては、こう書くだけでも動きます：
showError(result.error);
ただし：
- サーバー側の実装に完全依存
- JSON以外のレスポンスやネットワーク障害に弱い
→ プロダクション品質では非推奨です！
✨ おまけ：共通関数で管理するのもアリ
function getErrorMessage(result, res) {
return result.error || res.statusText || "Googleログインに失敗しました。";
}
showError(getErrorMessage(result, res));
- ロジックの再利用性が向上
- テスト・保守・ローカライズ（翻訳）にも強くなる
📌 総まとめ
| 候補 | 目的 | 備考 |
|---|---|---|
result.error |
一番具体的でユーザー向けに書かれた内容 | FastifyやExpressの res.send({ error: ... }) に対応 |
res.statusText |
HTTPレベルでのエラー内容 | fetch失敗などの基本保険 |
| デフォルト文字列 | 最低限の安心メッセージ | すべてが失敗したときのため |
→ この3段構成で「安心して壊せる」フロントが作れます。