「動く」コードと「落ちない」コードは違う

「動く」コードと「落ちない」コードは違う

プログラミング学習中に書くコードは、正常系（うまくいくパターン）だけを想定していることが多いです。しかし、本番環境で動くコードは異常系（うまくいかないパターン）への対応が不可欠です。

• APIが応答しない
• ユーザーが想定外の値を入力する
• データベースへの接続が切れる
• 外部サービスがメンテナンス中

こうした「想定外の事態」は、本番環境では日常的に起こります。エラーハンドリングは、コードの品質を決定づける重要なスキルです。

エラーハンドリングの基本原則

原則1：エラーを握りつぶさない

最もやりがちなミスは、try-catchでエラーをキャッチしたのに、何もしないことです。

エラーを握りつぶすと、問題が発生しても気づけず、原因不明の不具合として後から表面化します。

エラーをキャッチしたら、最低限以下のいずれかを行いましょう：

• ログに記録する
• ユーザーにエラーメッセージを表示する
• 上位の処理にエラーを再スローする

原則2：ユーザーにシステムエラーの詳細を見せない

エラーのスタックトレースやデータベースの情報をそのままユーザーに表示するのはセキュリティリスクです。

原則3：エラーの種類を区別する

すべてのエラーを同じように扱うのではなく、種類に応じた対応をしましょう。

• バリデーションエラー — ユーザーに修正方法を具体的に伝える
• 認証・認可エラー — ログインページへリダイレクトする
• サーバーエラー — ユーザーには一般的なメッセージを表示し、エンジニアには詳細ログを記録する
• ネットワークエラー — リトライの仕組みを提供する

フロントエンドのエラーハンドリング

API通信のエラーハンドリング

フロントエンドからAPIを呼び出す際は、必ずエラーハンドリングを実装しましょう。

考慮すべきケース：

• ネットワークエラー — ユーザーがオフラインのとき
• タイムアウト — APIの応答が遅いとき
• ステータスコードエラー — 400系、500系のレスポンス
• レスポンスのパース失敗 — JSONではないレスポンスが返ってきたとき

UIでのエラー表示

• インラインエラー — フォームの入力欄の横にエラーメッセージを表示する
• トースト通知 — 一時的なエラーを画面の隅に表示する
• エラーページ — 致命的なエラー時に専用のエラーページを表示する
• エラーバウンダリ — Reactのエラーバウンダリで、コンポーネントのクラッシュをキャッチする

バックエンドのエラーハンドリング

ログの設計

本番環境では、console.logではなく構造化されたログを記録します。

ログに含めるべき情報：

• タイムスタンプ
• エラーの種類・メッセージ
• リクエストの情報（URL、パラメータ、ユーザーID）
• スタックトレース
• 重要度（info、warn、error）

外部サービスとの連携

本番環境では、エラーをモニタリングサービスに送信して、リアルタイムで検知・通知する仕組みを導入します。

未経験エンジニアがやりがちなエラーハンドリングのミス

1. すべてのエラーに同じメッセージを表示する

「エラーが発生しました」だけでは、ユーザーは何をすればいいかわかりません。エラーの種類に応じて、具体的な対処法を示しましょう。

2. ハッピーパスしかテストしない

正常系だけでなく、異常系のテストも必ず行いましょう。

• 空の値を送信したらどうなるか
• 存在しないIDを指定したらどうなるか
• 権限のないユーザーがアクセスしたらどうなるか

3. リトライの仕組みがない

一時的なネットワークエラーの場合、リトライすれば成功することがあります。ただし、無限にリトライしないよう、回数制限と間隔の設定が必要です。

エラーハンドリングは「ユーザーへの誠実さ」

エラーハンドリングを丁寧に実装するのは、ユーザーに対する誠実さの表れです。エラーが起きても適切に対処されるアプリケーションは、ユーザーの信頼を獲得します。

ゆめさくエンジニアの18ヶ月カリキュラムでは、本番環境を意識したコーディングを実践的に学びます。エラーハンドリング、ログ設計、モニタリングまで、現場で必要なスキルを総合的に身につけられる環境です。

読みやすいコードの書き方

コードレビューで指摘されない5つの習慣

Webエンジニアのセキュリティ基礎

XSS・CSRF・SQLインジェクションを理解する

現場で通用するエンジニアスキル

スクールでは学べない実務力の全体像

ゆめさくエンジニアのカリキュラム

18ヶ月で実務力を身につける実践型カリキュラム