30代的挨踢人

例外と例外階層について

Microsoft® .NET 共通言語ランタイム (CLR) は、例外を生成するモジュールが、例外の処理を行うモジュールとは異なる言語で書かれている場合でも、プログラムに対して例外を統一的な方法で通知することができるプラットフォームを用意しています。

例外は、コード内の暗黙の仮定に対する違反を表しています。たとえば、コードが存在を仮定しているファイルにアクセスしようとしたが、そのファイルが存在しなかった場合には、例外が送出されます。しかし、コードがそのファイルの存在を仮定しておらず、先にファイルの存在をチェックしているようなシナリオでは、例外は必ずしも生成されません。

例外は必ずしもエラーとは限りません。例外がエラーを表すかどうかは、その例外が発生したアプリケーションによって決定されます。ファイルが発見できなかったときに送出される例外がエラーを表すかどうかは、シナリオによって異なります。

すべての例外クラスは、共通言語仕様 (CLS) に準拠して、System 名前空間内の Exception 基本クラスから派生されなくてはなりません。.NET Framework クラス ライブラリ (FCL) は、さまざまなタイプの一般的な例外を処理するために、網羅的な例外階層を用意していますが、これらはいずれも最終的には Exception から派生しています。例外は .NET ランタイムが生成することもあり、プログラム的に作成することもできます。独自の例外階層を作成する方法については、このドキュメントで後に詳しく説明します。

ApplicationException は、すべてのアプリケーション固有の例外クラスの基本クラスとなります。これは Exception から派生していますが、拡張機能は持っていません。カスタム アプリケーション例外は ApplicationException から派生させます。図 1 は、基本的な例外クラス階層を示しています。

図 1. 例外クラス階層

例外は適切に使用する

例外の送出は、コードの仮定に外れた条件が発生したときにのみ行います。言い換えると、意図した機能を提供するための手段として例外を使用してはなりません。たとえば、ユーザーはアプリケーションにログオンするときに無効なユーザー名やパスワードを入力することがあります。この場合、ログオンは成功しませんが、これは予期された有効な結果であり、例外が送出されるべきではありません。一方、ユーザーデータベースが使用不可能であるというような予期しない条件が発生したときには、例外を生成します。例外の送出は、単に呼び出し元に結果を返すよりもコストがかかります。このため、コード内の通常の実行の流れを制御する目的で例外を使用するべきではありません。また、例外を多用すると、読みにくく、管理が難しいコードになってしまう可能性があるので注意してください。

CLR がインターセプトする例外

シナリオによっては、送出した例外がランタイムによってキャッチされ、別の型の例外が元の例外の代わりに呼び出しスタック上に送出されることがあります。たとえば、オブジェクトの ArrayList の Sort メソッドを呼び出す場合を考えてみましょう。いずれかのオブジェクトが IComparable インターフェイスの CompareTo メソッドの中で例外を送出する場合、その例外はランタイムによってキャッチされ、Sort メソッドを呼び出したコードに対して System.InvalidOperationException 例外が送出されます。さらに、リフレクションを通して呼び出したメソッドによって送出されたすべての例外は、ランタイムによってキャッチされ、コードに対して System.Reflection.TargetInvocationException が送出されます。これらのシナリオでは、元の例外は失われません。これはランタイムによって送出される例外の InnerException として設定されます (InnerException プロパティについては「例外の伝播」のセクションで説明します)。このような状況はさまざまなシナリオで起こりえます。この点を理解し、このようなシナリオの影響を最小限に抑えるために、アプリケーションを徹底的にテストするようにしてください。

これらのトピックの詳細については、以下を参照してください。

InnerException を使用する状況

例外をラッピングするのは、そのための十分な理由があるときに限ってください。例外が最初に送出されるときには、例外の具体的な原因に関する情報が提供されます。例外が呼び出しスタック上を伝播する過程で、例外型の具体性は低下していきます。例外をラッピングすることによって、呼び出し元により具体的な例外を提供することができます。

たとえば、LoadUserInfo という架空のメソッドを考えてみましょう。このメソッドは、アクセスを試みたときに存在すると仮定されるファイルから、ユーザーの情報をロードするものとします。ファイルが存在しなければ、FileNotFoundException が送出されます。この例外は、LoadUserInfo メソッドの中で、ある特定の意味を持っています。しかし、この例外が呼び出しスタック上を伝播し、たとえば LogonUser メソッドに到着したとき、FileNotFoundException 例外は意味のある情報を何も提供しなくなっています。FileNotFoundException を (後に説明する) カスタム例外クラス、たとえば FailedToLoadUserInfoException という名前の例外クラスにラッピングし、ラッパー例外を送出すれば、呼び出し元の LogonUser メソッドにとってより意味のある情報を提供することができます。LogonUser メソッドの中では、FailedToLoadUserInfoException 例外をキャッチし、この例外型に対処するようにすれば、別のメソッドの実装上の細部でしかない FileNotFoundException をキャッチする必要はなくなります。

アプリケーション例外階層の設計

.NET Framework は、例外クラスの網羅的な階層を用意しています。.NET Frameworkが適切な例外クラスをすでに提供している場合には、新しいクラスを作成するのではなく、既存のクラスを使用してください。コード内で対処と処理を必要とする例外型のための新しいアプリケーション例外クラスを作成するのは、アプリケーション例外階層または Framework内に適切なクラスがない場合に限ってください。ほとんどのアプリケーション例外階層はかなりフラットなものになり、グループ化は整理の目的のため、または少数のアプリケーション例外のセットで共通のプロパティまたは機能を継承できるようにするために使用されることになるでしょう。

独自の階層を作成する際には、以下の質問をもとに、新しい例外クラスを作成する必要があるかどうかを判断してください。

• この条件で対処する例外は存在するか?
  現在の階層または Framework の中に例外が存在する場合には、独自の例外クラスを作成するのではなく、既存の例外を使用します。
• その例外に特別な処理は必要か?
  必要ならば、コードでその例外をキャッチし、明示的に処理が行えるように、新しい例外クラスを作成するべきです。これにより、より一般的な例外をキャッチし、条件付きロジックを使って実行すべきアクションを決定する必要がなくなります。
• その例外について特殊な振る舞いや追加の情報が必要か?
  必要ならば、新しいアプリケーション例外クラスを使って、個々のニーズに合わせて情報や機能を追加することができます。

アプリケーション例外階層は、アプリケーション コード全体から参照できる 1 つのアセンブリ (大きなシステムの場合は少数のアセンブリのグループ) に格納するようにしてください。これにより、例外クラスの管理と導入を集中化することができます。

カスタム例外クラスの作成

名前の標準化を図るために、カスタム例外クラスの名前はつねに Exception という名前で終わらせるようにします。また、個々のカスタム例外クラスについて、次のクラス定義に示す 3 つのコンストラクタを用意しておくことをお勧めします。

using System;
public class YourBaseApplicationException : ApplicationException
{
   // デフォルト コンストラクタ
   public YourBaseApplicationException ()
   {
   }
   
   // 1 つの文字列メッセージを受け付けるコンストラクタ
   public YourBaseApplicationException (string message) : base(message)
   {
   }
   
   // 1 つの文字列メッセージと、このカスタム例外クラスによって
   // ラッピングされる内側例外を
   // 受け付けるコンストラクタ
   public YourBaseApplicationException(string message, 
            Exception inner) : base(message, inner)
   {
   }
}

基本アプリケーション例外クラスの作成

アプリケーションは、ApplicationException から派生する 1 つの基本例外クラスを持つべきです。このクラスは、前に図 5 に示したように、アプリケーションのすべての例外クラスの基本クラスの役割を果たします。

この基本クラスにフィールドを追加して、例外が発生した日付と時刻やマシン名といった具体的な情報をキャプチャするようにします。これにより、例外に関する一般的な詳細情報が 1 つの基本クラスにカプセル化され、他の例外クラスはこの情報を継承を通して利用できるようになります。

カスタム例外のリモート管理

Exception クラスは ISerializable インターフェイスを実装しており、シリアル化を独自に管理することができます。例外をリモーティング境界上でマーシャリングできるようにするためには、クラスに [Serializable] 属性を追加し、次に示すコンストラクタを追加する必要があります。

protected YourBaseApplicationException(SerializationInfo info,
      StreamingContext context) : base(info, context)
{
}

例外が ApplicationException 基本クラスにフィールドを追加している場合は、これらの値をシリアル化されたデータ ストリームにプログラム的に永続化する必要があります。これは GetObjectData メソッドをオーバーライドし、次に示すようにこれらの値を SerializationInfo オブジェクトに追加することによって実現できます。

[Serializable]
public class ExampleException : ApplicationException
{
   public ExampleException() : base()
   {
   }
   public ExampleException(string message) : base(message)
   {
   }
   public ExampleException(string message,Exception inner) :
                  base(message,inner)
   {
   }
   protected ExampleException(SerializationInfo info, StreamingContext context) : 
                  base(info,context)
   {
      m_strMachineName = info.GetString("m_strMachineName");
   }

   public override void GetObjectData( SerializationInfo info,
                  StreamingContext context )
   {
      info.AddValue("m_strMachineName", m_strMachineName,
                  typeof(String));

      base.GetObjectData(info,context);
      }

   private string m_strMachineName = Environment.MachineName;

   public string MachineName
   {
      get
      {
         return m_strMachineName;
      }
      set
      {
         m_strMachineName = value;
      }
   }
}

SerializationInfo オブジェクトの値は、例外オブジェクトのコンストラクタの中で、info.GetValue か、SerializationInfo オブジェクトのいずれかの Get メソッド (上に示した GetStringなど)を使って取得することができます。カスタム例外は、ローカルとリモートの境界上でマーシャリングされるときに、自分の状態を保持できなくてはなりません。アプリケーションが現時点でリモーティング境界を越えていない場合でも、シリアル化をサポートすることで、アプリケーションが後に変更された場合でも例外情報が失われないようにすることができます。例外のカスタム値をプログラム的にシリアル化していないと、クライアントで逆シリアル化(deserialize)されたときに、それらの値は正しく設定されません。また、シリアル化をサポートすることで、アプリケーションは例外に関するすべての情報をシリアル化し、ログの記録の目的のために格納できるようになります。

これらのトピックの詳細については、以下を参照してください。

ASP.NET

ASP.NET では、スクリプティング言語の貧弱な機能に頼る必要はなくなっています。ASP.NET のコードはコンパイルされ、任意の.NET Framework 言語で書くことができます。従来の ASP の世界のテクニックの貧弱さとは対照的に、ASP.NETのページはコンポーネントと同じあらゆる例外処理テクニックを利用することができます。ASP.NETはいくつかの具体的な機能により、アプリケーションが例外を管理し、ユーザーに対する情報の表示方法を構成できるようにしています。

Web.config 設定

例外管理設定は、アプリケーションの Web.config ファイルの中で構成します。次に、Web.config ファイルの中の例外設定の例を示します。

<customErrors defaultredirect="http://hostname/error.aspx" mode="on">   
  <error statuscode="500" redirect="/errorpages/servererror.aspx" />
  <error statuscode="404" redirect="/errorpages/filenotfound.htm" />
</customErrors>

customErrors 要素では、デフォルト リダイレクト ページを指定します。デフォルト リダイレクト ページには 3 つのモードがあります。

• on
  未処理例外は、ユーザーを指定された defaultredirect ページにリダイレクトします。これは主にプロダクション環境で使用されます。
• off
  ユーザーに対して例外情報が表示され、defaultredirect ページへのリダイレクトは行われません。これは主に開発環境で使用されます。
• remoteonly
  ローカル マシン上のサイトに (localhost を使って) アクセスするユーザーのみに例外情報が表示され、その他のすべてのユーザーは defaultredirect ページにリダイレクトされます。これは主にデバッグのために使用されます。

デフォルト リダイレクト ページに加えて、特定の HTTP エラー コード用のページを設定することができます。たとえば、すべての 404エラーで特定のエラー ページが表示され、すべての 500 エラーで別のページが表示されるようにすることができます (上の例を参照)。

.NET 以前には、これらの設定は Internet Information Services (IIS)メタベースの中で構成する必要がありました。ASP.NET の Web.config ファイルは、アプリケーションの構成設定を 1つのファイルに集中化し、アプリケーションとその設定の xcopy 導入を可能にしています。

これらの設定は ASP.NET ファイルにのみ適用されることに注意してください (.aspx や.asmxなどの特定の拡張子のファイル)。たとえば、ユーザーが Web サーバー上に存在しない.htm ファイルや.aspファイルを要求した場合、IIS は Web.config ファイルではなく IIS メタベースに定義されている HTTPエラー設定に基づいてユーザーをリダイレクトします。ASP.NET ファイルと非 ASP.NET ファイルの間に一貫性を持たせたい場合は、IISと Web.config ファイルを、ユーザーを同じページにリダイレクトするように構成します。IISメタベースの中のすべての設定を、アプリケーション ファイルとともに導入しなくてはなりません。

@ Page ディレクティブ

Web.config ファイルの設定は、そのディレクトリとすべての子ディレクトリに適用されます。これらの設定は、Page ディレクティブの ErrorPage 属性を使って、特定のページについてオーバーライドすることができます。次に例を示します。

<%@ Page ErrorPage="customerror.aspx" %>

このサンプルは、Web.config の設定にかかわらず、現在のページの中で未処理の例外が発生した場合には、ユーザーを customerror.aspx にリダイレクトします。

ASP.NET 例外の処理

ASP.NET は、アプリケーション コードから伝播した未処理例外に対処するためのイベントを主に 2 つ用意しています。

• Page_Error
  このイベントは、例外がページ レベルで処理されなかったときに発生します。このイベントを発生させるためには、ページのコード内に Page_Error イベントを含め、@ Page ディレクティブの AutoEventWireup 属性が true (規定値) に設定されているかどうかを確認するか、次のコードを使ってイベントを手動でフックアップします。

  Page.Error += new System.EventHandler(Page_Error);
  

• Application_Error
  これは global.asaxファイルに置かれており、そのためにアプリケーション全体のスコープを持っています。この例外は、特定のページによって例外が処理されなかった場合に発生します。このイベントは、ユーザーにエラーを手際よく返す前に、ログの記録、通知、およびその他の必要な処理を実行するために使用します。

  // global.asax ファイル
  protected void Application_Error(Object sender, EventArgs e)
  {
        Exception exc = Server.GetLastError();
        // ログの記録の実行、通知の送信などを行う。
  }
  

これらのイベントでは、Server.GetLastError メソッドを使って、未処理例外オブジェクトへの参照を取得します。Server.ClearError を使って例外をクリアし、それ以降の伝播を止めることもできます。たとえば、ページに、Server.GetLastError を使って未処理例外オブジェクトにアクセスする Page_Error イベントがあったとします。Server.ClearError を使って例外をクリアしなければ、未処理例外は Application_Error イベントまで伝播します。Application_Error 内で Server.ClearError を使って例外をクリアすると、未処理例外は存在しなくなるため、web.config ファイル内の defaultredirect 設定はユーザーをリダイレクトしなくなります。defaultredirect に正しくユーザーをリダイレクトさせたい場合は、Application_Error 内で例外をクリアしないようにしてください。

これらのトピックの詳細については、以下を参照してください。

適切な情報をキャプチャする

各グループが、それぞれにとって意味のある情報を受け取り、適切に対処できるようにすることが重要です。すべての情報がすべてのオーディエンスにとって適切であるとは限りません。たとえば、ユーザーに対して、ソースコードの行番号や、インデックスが範囲を超えたなどのプログラム上の条件を含んだ意味不明なメッセージを表示するべきではありません。エンドユーザーを同じほど困惑させるのが、「エラーが発生しました。システム管理者に連絡してください」というような一般的に過ぎるメッセージです。ユーザーに対しては、問題の解決につながるアクションを含む、何らかの役立つメッセージが表示されなくてはなりません。つねにすべての関連情報をキャプチャし、受信者のニーズに基づいて情報をフィルタリングした上で表示するようにしてください。

アプリケーションが各種のグループに応じて調整できるリッチな情報を提供できるように、次の表に示す詳細情報をキャプチャするようにしてください。「ソース」の欄は、この情報を生成できるクラスとクラス メンバを示しています。特に記していない限り、すべてのクラスは System 名前空間に含まれています。

すべての例外データへのアクセス

例外はさまざまな構造を持ち、例外の原因に関する貴重な情報を提供するさまざまなパブリック プロパティを公開することができます。何が異常を来したのかを完全に把握できるように、これらの情報すべてをキャプチャすることが重要です。(System.Reflection 名前空間で実装されている) リフレクションを使用することで、例外のパブリック プロパティのすべての値に簡単にアクセスすることができます。これは、Exception型の引数を受け付ける汎用的なログ記録ルーチンに便利です。このようなルーチンは、リフレクションを使って、詳細で具体的な例外情報を問い合わせ、アクセスすることができます。開発者が例外のソースを判断できるように、例外に関する十分な詳細情報をキャプチャすることが重要となります。

これらのトピックの詳細については、以下を参照してください。

Windows イベント ログの使用

Windows 2000 および Windows NT® オペレーティング システムは、いくつかのイベントログのセットを提供しています。たとえば、オペレーティング システムはエラーの詳細をシステム イベントログに格納しますが、アプリケーションが使用するためのアプリケーション イベント ログも用意されています。また、共有のアプリケーション イベントログを使用する代わりに独立したイベント ログを作成することで、アプリケーションのログ エントリを分離することができます。イベント ログは、1つのマシン上のエラー、警告、および情報メッセージのための一貫性のある中央のストレージ リポジトリの役割を果たします。.NETFramework はログの記録と監視を容易にするイベント ログ関連のクラスを持っています。

長所

• 情報をログに記録するための、きわめて信頼性の高い手法です。
• Windows 2000 と Windows NT の両方で提供されています。
• ログ ファイル サイズを管理する機能があります。ユーザーは最大ログ サイズを構成し、レコードが保持される日数を指定するか、ログ ファイルを手動でクリアするよう指定することができます。
• イベント ビューアなどのツールを使って、ログ エントリを表示し、操作することができます。
• System.Diagnostics 名前空間の EventLog クラスなどの.NET Framework クラスにより、イベント ログのプログラムからの書き込みと保守を簡単に行えます。
• ほとんどの監視ツールは、イベント ログをイベント ソースとしてサポートしています。
• イベント ログは Windows Management Instrumentation (WMI) と緊密に統合されています。
• システム管理者とオペレータは、一般にイベント ログとその関連ツールに慣れています。
• オペレーティング システムと多くのアプリケーションはイベント ログに記録するので、システム イベントとアプリケーション イベントのシーケンスを簡単に比較することができます。

短所

• 個々のマシンがローカル イベント ログに記録します。このため、大規模なサーバーファームでは、監視と保守の点で問題が生じることがあります。別のマシン上のログにエントリを書き込むこともできますが、この方法は障害のリスクが高くなるので使わないようにしてください。

Microsoft Application Center Server やいくつかのサードパーティ ソフトウェアパッケージでは、複数のサーバーのローカル イベント ログを集中化することができます。この場合には、複数のイベント ログを 1つのエンティティとして表示することができます。

Windows イベント ログの使用方法の詳細については、以下の Web サイトを参照してください。

監視アプリケーションの使用

監視システムのある環境では、いくつかの方法で通知を提供することができます。

• アプリケーションは、ログの監視と、検出されたエラー条件への対応を監視システムに任せることができます。
• 監視システムに通知を行うために、イベントを予防的に生成するコードを実装することができます。監視システムに特定の情報を予防的に通知する方法としては、Windows Management Instrumentation (WMI) が推奨されます。

ログ データ ストアの監視

ログを監視し、メッセージの到着を監視するように監視システムを構成することができます。さらに、特定のメッセージのセットのみに、あるいは特定の条件にマッチするメッセージ、たとえば定義済みのエラーレベルを超えたメッセージのみに反応するよう、モニタを微調整することもできます。Application Center Serverなどのツールは、イベント ログに記録された特定の情報を検出し、事前に構成された設定に基づいてアクションを実行することができます。

長所

• 監視システムはアプリケーション コードから分離されます。
• ログ記録の実装以外に追加のコードが不要です。

短所

• ログをポーリングし、処理の必要があるレコードをフィルタリングするよう、監視システムを構成する必要があります。
• これらのイベントを処理する他の全システムについても、選択されたログを監視するよう構成しなくてはなりません。

相互運用性 (Interop)

CLR は、マネージ コードとアンマネージコードを連動させるためのさまざまな相互運用性機能を提供しています。これは例外処理にも当てはまります。COMクライアントが例外を送出するマネージ クラスを呼び出すと、CLR はそれをキャッチし、アンマネージ COM コードに理解できる HRESULTに変換します。同じように、COM コンポーネントがマネージ コードに失敗を示す HRESULT を返した場合、CLR は HRESULTを例外に変換し、COM IErrorInfo インターフェイスが提供する追加情報を例外オブジェクトに組み込みます。CLR が HRESULT を認識できなかった場合には、ErrorCode プロパティを認識されない HRESULT 値に設定した総称 COMException オブジェクトを返します。

.NET Framework クラス ライブラリ (FCL) の例外の多くは、COM コンポーネントにまったく新しい HRESULT値を返します。この場合、既存の COM コードは HRESULT を理解できません。COM コードが、失敗を表す HRESULTをもとに何らかのアクションを実行している場合には、COM コードに渡す前に例外の HRESULT値を変更するようにしてください。例外オブジェクトの HResult プロパティは、アンマネージ コードに返されるHRESULT 値を表しています。これは読み書き可能なプロパティで、COMコードを正常に動作させるために任意の値に設定することができます。さらに、アンマネージ COM コードと対話を行うアプリケーション例外は、HResult プロパティをオーバーライドし、デフォルトとして例外条件を正確に表す HRESULT 値を設定するようにする必要があります。

相互運用性の詳細については、以下を参照してください。