Last updated on

エラーハンドリングの種類を整理し、状況に合わせて選ぶ（AI生成コードのレビュー観点）

  • エラーハンドリング
  • Web制作
  • 品質
  • AI

Web 制作では、壊れたデータ、ツールの挙動、想定外の入力がいつか必ず出てきます。ここでは、どんな種類の「エラーへの備え」があるかを整理し、状況に応じてどれを優先するか、さらに AI にコードを書いてもらうときにレビューで押さえたい点まで、一文脈でまとめます。

三つの軸で整理する

狭義の「例外処理」だけに語を寄せると、CSS の未対応や ビルドの失敗など、別レイヤの話がすれ違いやすいです。まず次の 三つ に分けると、議論と実装の両方が追いやすくなります。

  1. エラーがあっても、ページの表示を崩さない
  2. エラーがあっても、処理を止めない
  3. エラーがあったら、気づけるようにする（通知・失敗として見える）

目的はどれも「体験やデータを守る」に近いですが、守り方が違うので、案件やレイヤごとに どれを厚くするかを選びます。

1. 表示を崩さない

  • 値が未登録だったり、想定と型が違うときは、無理に出さない（出さない・既定値にする・別要素にするなど、方針は案件で決める）。
  • CSS でまだ広く効かないプロパティを使うときは、必要に応じて フォールバック を書く。
    ただし 当たらなくても致命的に崩れないなら、フォールバックなしでシンプルに寄せる判断もあり得ます。

ここは 利用者に見える部分 の話です。狭義の「例外」とは別語彙になりがちですが、**「想定と違う状態でも見た目が破綻しない」**という意味では、同じ棚に並べてよい軸です。

2. 処理を止めない

  • 例として、Gulp まわりの制作環境では、SCSS の構文エラーがあっても後続タスクを止めず、とりあえずページを見られるようにしている構成があり得ます。**「作業を進める」**には効きます。
  • JavaScript や PHP で関数名を変えるとき、古い名前を呼んでも動くようにする、というのも「止めない」に近い対応です。
    ただし 互換性を保つ必要がある場面（公開 API、複数サイトで共有されるスクリプトなど）に限定したほうがよく、不要なら 記述が複雑になり、読みやすさや保守性が下がるだけになりがちです。

本番公開では「エラーがあっても処理を止めない」が利用者体験として有利なことが多い一方、開発中は **「エラーがあったらそこで止まる／赤く出る」**ほうが、品質のよいものを作りやすい、という切り分けが重要です。
同じ「エラーへの備え」でも、フェーズで最適解が逆になる、という整理です。

3. エラーがあったら通知する（＝失敗として見える）

Gulp や Vite などのタスクランナーを使っている場面では、Sass（SCSS）の記述ミスがあったときに、パイプラインを止めずに後続へ進む構成と、そこで処理を止めてエラーを出す構成の両方があり得ます。ツール名以前に、設定とプラグインの組み合わせでどちらに寄るかが変わります。

書いている最中にエラーが出るのは煩わしく感じることもありますが、ミスにすぐ気づけるというメリットのほうが大きい、という整理に寄せることもあります。
一方、エラーを表に出さない（止めない）環境は作業は進めやすい反面、ミスに気づきにくい、というトレードオフです。

「通知」は、コンソール・ビルド失敗・型チェック・CI の赤、など 形はさまざまですが、共通しているのは 開発者が早い段階で検知できることです。

状況に応じて、適切な対応を選ぶ

三つの軸は、すべてを常に最大限やるという意味ではありません。

  • 表示: ガードしすぎると経路が読みにくくなる。守るべき核（レイアウトの致命傷、誤表示による誤解など）から厚みを決める。
  • 止めない: 本番向けの耐性と、開発での 失敗の早期露出 は別問題。開発では「止まる」ほうがよいことが多い。
  • 通知: 誰が・いつ・何を直すチャネルか（ローカル、レビュー、本番ログ）を決めたうえで、ツールや設定を選ぶ。

線引きを文章やルールにしておかないと、都度の場当たりや 過剰な try/catch・握りつぶし に寄りやすいです。

AI が書きがちなことと、レビューで見るポイント

AI にコードを書いてもらうと、**「エラーがあっても処理を止めない」**方向のコードになりがちです。握りつぶし、広い catch、常にデフォルト値、などが典型です。

それが悪いとは限りません。本番でユーザー体験を守る用途では有効なことも多いです。一方で、次のような場面では **「エラーを出す／ビルドを落とす／型で弾く」**ほうが適切です。

  • 開発中に、ミスにすぐ気づきたい（前述の Sass や型、lint など）。
  • データの不整合を黙って続行すると、後から直しにくい汚染が起きる。
  • 互換レイヤやフォールバックが不要な内部コードで、複雑さだけが増える。

レビューでは、**「この失敗は、誰が・いつ気づく設計になっているか」**を繰り返し確認するとよいです。AI 案をそのまま「親切なコード」として受け取る前に、**フェーズ（開発／本番）と、守りたいもの（表示・データ・開発速度）**に照らして、握りつぶし続行が本当に適切かを切り替える、というスタンスが合います。

まとめ

  • エラーへの備えは、表示を守る・処理を止めない・失敗を見える化するの三軸で整理すると、レイヤの違い（CSS・ビルド・サーバ・クライアント）を同じ表で語りやすい。
  • 本番と開発では、止めない／止めるの最適解が違うことが多い。
  • AI 生成コードは「止めない」寄りになりやすいので、開発時の検知と不要な複雑化の両方をレビューで押さえる。

細かい記法やパターンは、使っているスタックの公式ドキュメントと、プロジェクトのコーディング規約を正にしてください。