エラー処理をパターンにはめよう

実例で学ぶASP.NET Webフォーム業務アプリケーション開発のポイント 第3回

独自のエラーページの表示

　ASP.NETでは例外が発生すると、俗にYSOD（Yellow Screen Of Death）と呼ばれる標準のエラーページを表示します。このエラーページには例外の発生元を表すスタックトレースや、詳細なエラーメッセージが表示されます。

　しかし、一般のユーザーにそのような情報を見せることはセキュリティの観点からも望ましくありません。

　ASP.NETでは「カスタムエラーページ」という仕組みを使用し、独自のエラーページを表示することができます。カスタムエラーページは、致命的なエラーが発生したことを表す簡単なメッセージとシステム管理者への連絡を促すメッセージが記載された静的Webページとして作るのが望ましいです。

　カスタムエラーページを表示するには、Web構成ファイル（Web.config）で以下のように設定します。

［リスト5］カスタムエラーページを表示するWeb.configの設定

<configuration>
  <system.web>
    <!-- (1) -->
    <customErrors defaultRedirect="~/ErrorPage.html"
                  mode="On" />  <!-- (2) -->
  </system.web>
</configuration>

(1) エラーページのURLを指定する

　configuration-system.webセクションのcustomErrors要素で、defaultRedirect属性にカスタムエラーページのURLを指定します。

(2) カスタムエラーページを必ず表示させる

　同じくcustomErrors要素でmode属性に"On"を設定します。

　これにより、システムエラー時は常にカスタムエラーページが表示されるようになります。

　なお、標準のエラーページを常に表示させるには"Off"、ローカルマシンで動かした場合は標準のエラーページ、リモートサーバーで動かした場合はカスタムエラーページが表示されるようにするには"RemoteOnly"を指定します（既定値はRemoteOnly）。

　それぞれの値は、次のように使い分けます。

• 個々の開発者によるPCでの作業中は既定値の"RemoteOnly"のままとし、標準エラーページを開発者が見られるようにする。
• テストサーバーに配置したテスト環境では"Off"にし、テスターに標準エラーページを見せ、開発者に知らせてもらう。
• 実運用環境では"On"にし、エンドユーザーには標準エラーページを見せない。

まとめ

　ASP.NET Webフォームアプリケーションでのエラー処理のポイントは、以下のとおりです。

• エラー処理をすべてイベントハンドラーに書くのはアンチパターン。
• エラーは次のように分類できる。
  • 単体入力エラー
  • 突合せエラー
  • システムエラー
• エラーの種類ごとに適切な方法で対処する。
• 単体入力エラーは検証サーバーコントロールを用いてチェックする。
• 突合せエラーはロジック層でチェックを行い戻り値でチェック結果を返す。プレゼンテーション層では返されたチェック結果を元にエラーメッセージを表示する。
• システムエラーは集約例外ハンドラーでまとめて対処する。そして、カスタムエラーページを使用し、エラーの詳細情報をエンドユーザーには見せないようにする。
• エラー処理は単体入力エラー→突合せエラーの順で行う。前段階でエラーがないときのみ以後の処理を行うことで、入力値の妥当性を確保して処理を進めることができる。

　さて、次回はASP.NET Webフォームアプリケーションにおける「状態管理」について、ケースごとにどのような状態管理を行えばよいのか紹介する予定です。次回もお楽しみに。