ASP.NETのエラー処理メカニズム

Webアプリケーションでは、エラーは避けられないため、発生する可能性のあるエラーに適切な処理を提供する必要があります.実際、良好なエラー処理メカニズムは、Webアプリケーションの良し悪しを測定する重要な基準です.考えてみてください.ユーザーがブラウザに誤ったURLを入力したり、ユーザーがいくつかの情報を提供してプログラムが間違っている場合、私たちがこれらの状況を処理していないで、404や500のエラーページやエラーのスタック情報をユーザーの前に提示したりすると、一部のユーザーが驚いて逃げるに違いありません.だから、私たちがWebアプリケーションを開発する時、ASPに対してNETエラー処理メカニズムは十分に理解されている.
ASPに戻りましょうNETでは、まず2つの質問をして考えてみましょう.ASP.NETエラー処理メカニズムはいくつありますか?いくつかのエラー処理メカニズムが同時に採用されている場合、それらの間には一定の優先度がありますか?この問題を持って、まず私たちが最もよく見ているWebを見てみましょう.Configファイル:

  

   
＜?xml version="1.0"?＞ 
   
＜configuration＞ 
   
 ＜system.web＞ 
   
   ＜customErrors mode="On" defaultRedirect="GenericErrorPage.htm"＞ 
   
     ＜error statusCode="403" redirect="Error403.htm" /＞ 
   
     ＜error statusCode="404" redirect="Error404.htm" /＞ 
   
   ＜/customErrors＞ 
   
＜/system.web＞ 
   
＜/configuration＞ 
  

＜customErrors＞という設定項目については、言うまでもなく、詳しくはMSDNのを参考にできると思います.第1のエラー処理メカニズム--Webを使用する.コンフィグの＜customErrors＞コンフィギュレーションアイテムは皆さんが一番よく使うはずです.
次に、もう一つよく使われるファイルを見てみましょう.Global.asax.この書類といえば、皆さんは何を思い浮かべましたか.はい、2つのWebアプリケーションオブジェクト(Application、Session)に関連するイベントです.これらのイベントには、Applicationのカテゴリーに属するエラーに関連するイベントであるErrorがあり、対応するイベント処理方法はApplication_Errorです.名前の通り、このイベント処理方法はアプリケーション・レベルのエラーが発生したときに呼び出されるため、次のようにコードを追加してエラーを処理できます.

  

   
protected void Application_Error(object sender, EventArgs e) { 
   
　Exception objErr = Server.GetLastError().GetBaseException(); 
   
　Response.Write("Error:" + objErr.Message); 
   
　Server.ClearError(); 
   
} 
  

ここでは、最後のコードサーバに注意してください.ClearError()の使用は、なぜこのコードを使用するのでしょうか.使わなければどうなるの?ここで私はまた先に関所を売った.2つ目のエラー処理メカニズムはGlobalを使用しますasaxでのApplication_Errorイベントの処理方法も登場した.
以上の2つのエラー処理方法はいずれもグローバルであると言える、1つはアプリケーションプロファイルから、もう1つはアプリケーションルートディレクトリの下に置かなければならないGlobalである.asaxファイルのイベント処理方法.グローバルとは対照的にローカルなので、ローカル--あるページに適用されるエラー処理メカニズムはありますか?答えは「あります」で、ErrorPageプロパティとPage_を使用する2つあります.Errorイベントの処理方法.最初のメカニズムでは、ErrorPageプロパティをいつでも設定して、ページにエラーが発生したときにどのページにリダイレクトするかを決定することができます.第2のメカニズムでは、Application_Errorイベントの処理方法は似ているが,トリガされるタイミングが異なるだけである.次の2つの例を示します.

  

   
＜script language="C#" runat="server"＞ 
   
protected void Page_Load(object sender, EventArgs e) { 
   
　this.ErrorPage = "ErrorPage.htm"; 
   
} 
   
＜/script＞ 
   
 
   
protected void Page_Error(object sender, EventArgs e) { 
   
　Exception objErr = Server.GetLastError().GetBaseException(); 
   
　Response.Write("Error:" + objErr.Message); 
   
　Server.ClearError(); //             
   
}  
  

これで、4種類のASP.NETエラー処理メカニズムがすべて登場し、順位をつける時だ.優先度が高い順にソート:Page_Errorイベント処理方法＞ErrorPageプロパティ＞Application_Errorイベント処理方法＞＜customErrors＞構成項目.ソートはそうですが、このソートの間にはまた微妙な関係があります.まず、ErrorPageプロパティを機能させるには、構成項目のmodeプロパティを「On」に設定する必要があります.次に、Page_Errorイベントの処理方法は先頭に立っているが,サーバが少なくなったら.ClearError()メソッドでは、Application_Errorイベントの処理方法も同様である.順序は並べられていますが、順序は最も重要な問題ではありません.あまり意味のない問題とも言えます.多くの場合、この4つの処理メカニズムを混合して使用しない可能性があります.最も重要な問題は、これらのエラー処理メカニズムをどのように選択するかだと思います.この問題については、経験のある友人が意見を述べてほしい.
さて、4種類のASPについてNETのエラー処理メカニズムはここまで紹介されていますが、自分の気持ちについてもお話ししましょう.ASP.NETの設計者は確かに開発者の立場に立って周到に考慮したので,我々が選択できる4つのエラー処理メカニズムを提供したことは称賛に値する.しかし、広告の言葉を使う--多くは惑わされ、私たちもこんなに多くの誤った処理メカニズムにめまいがします.J 2 EE領域でのエラー処理と比較して,比較的簡単であることが分かった.まずに対応する設定であり、J 2 EEプロジェクトで最もよく使われるwebからも利用できる.xmlファイルに類似の構成項目が見つかりました:;次に、J 2 EEの分野では、Pageは重要なエンティティではなく、イベント駆動モデルも必要ではないので、Application_とは本当に見つかりませんでした.ErrorとPage_Error法に対応する処理機構;最後に、J 2 EEの分野では、RequestとResponseが強調されていますが、論理処理でエラーが発生すると、RequestDispatcherを通じてRequestを対応するエラー処理モジュールに簡単に配布することができます.実際には非常に柔軟な処理方法ですので、興味のある方はご理解ください.