Web アプリケーションの場合、エラーは避けられないため、予防策を講じ、発生する可能性のあるエラーに適切に対処する必要があります。実際、優れたエラー処理メカニズムは、Web アプリケーションの品質を測定するための重要な基準です。想像してみてください。ユーザーが誤ってブラウザに間違った URL を入力した場合、またはユーザーがプログラムにエラーを引き起こす情報を入力した場合、これらの状況に対処しなければ、404 または 500 のエラー ページ、さらにはスタック情報が発生する可能性があります。がユーザーの目の前に提示されると、一部のユーザーは間違いなく怖がってしまいます。したがって、Web アプリケーションを開発するときは、エラー処理メカニズムを完全に理解する必要があります。
ASP.NET に戻って、誰もが考えられる 2 つの質問をしてみましょう。ASP.NET には、エラー処理メカニズムがいくつ提供されていますか?複数のエラー処理メカニズムが同時に使用される場合、それらの間に特定の優先順位はありますか?この質問を念頭に置いて、まず最も一般的な Web.Config ファイルを見てみましょう:
<?xml version="1.0"?>
<構成>
<システム.ウェブ>
<customErrors mode="On"defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="Error403.htm" />
<error statusCode="404" redirect="Error404.htm" />
</カスタムエラー>
</system.web>
</設定>
<customErrors> の設定項目については、もう言うまでもないと思いますが、詳しくはMSDNを参照してください。最初のエラー処理メカニズムは、Web.Config の <customErrors> 構成項目を使用するもので、最も一般的に使用されます。
次に、同じく非常によく使用される別のファイルである Global.asax を見てみましょう。この文書について言うとき、何を思い浮かべますか?はい、これらは 2 つの主要な Web アプリケーション オブジェクト (アプリケーションとセッション) に関連するイベントです。これらのイベントの中には、アプリケーション カテゴリ - Error に属するエラー関連イベントがあり、対応するイベント処理メソッドは Application_Error です。名前が示すように、このイベント処理メソッドはアプリケーション レベルのエラーが発生したときに呼び出されるため、以下に示すように、このメソッドにエラーを処理するコードを追加できます。
protected void Application_Error(object sender, EventArgs e) {
例外 objErr = Server.GetLastError().GetBaseException();
Response.Write("エラー:" + objErr.Message);
Server.ClearError();
ここ
で、コードの最後の行で Server.ClearError() が使用されていることに注意してください。なぜこのコード行を使用する必要があるのでしょうか。使用しない場合はどうなりますか?ここでもう一度試してみます。さて、Global.asax の Application_Error イベント処理メソッドを使用する 2 番目のエラー処理メカニズムもデビューしました。
上記の 2 つのエラー処理メソッドはグローバルであると言えます。1 つはアプリケーション構成ファイルから派生したもので、もう 1 つはアプリケーションのルート ディレクトリに配置する必要がある Global.asax ファイルのイベント処理メソッドです。グローバルの反対はローカルです。したがって、ローカル、つまり特定のページに適用されるエラー処理メカニズムはあるだろうか、と当然疑問に思います。答えは「はい」です。方法は 2 つあります。ErrorPage 属性を使用する方法と、Page_Error イベント処理メソッドを使用する方法です。最初のメカニズムでは、ほぼいつでも ErrorPage プロパティを設定して、ページでエラーが発生したときにどのページにリダイレクトされるかを決定できます。2 番目のメカニズムは、Application_Error イベント処理メソッドと非常によく似ています。発動するタイミングが違います。以下に 2 つの具体的な例を示します。
<script language="C#" runat="server">
protected void Page_Load(オブジェクト送信者, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</script>
protected void Page_Error(オブジェクト送信者, EventArgs e) {
例外 objErr = Server.GetLastError().GetBaseException();
Response.Write("エラー:" + objErr.Message);
Server.ClearError(); //このコードの使用にも注意してください
この
時点で、4 つのエラー処理メカニズムがすべて登場したので、それらをランク付けします。優先度の高いものから低いものへと並べ替えます: Page_Error イベント処理メソッド > ErrorPage プロパティ > Application_Error イベント処理メソッド > <customErrors> 構成項目。このようなランキングですが、順位には微妙な関係があります。まず、ErrorPage 属性を機能させるには、<customErrors> 構成項目の mode 属性を「On」に設定する必要があります。次に、Server.ClearError() メソッドが優先されている場合は、Page_Error イベント処理メソッドが優先されます。 missing 場合でも、優先度の低いエラー処理がトリガーされます。これは、Application_Error イベント処理メソッドにも当てはまります。順序は整理されていますが、順序は最も重要な問題ではなく、多くの場合、これら 4 つの処理メカニズムを混在させることはできないため、あまり意味のない問題であるとさえ言えます。最も重要な問題は、これらのエラー処理メカニズムをどのように選択するかであると思います。この問題については、経験豊富な友人が意見を共有できることを願っています。
さて、ASP.NET の 4 つのエラー処理メカニズムの紹介はこれで終わりです。ここからは私自身の感じたことをいくつか話していきます。 ASP.NET の設計者は開発者の観点から徹底的に検討しており、選択できるエラー処理メカニズムを 4 つも提供しており、これは賞賛に値します。しかし、広告のスローガンを言い換えると、多すぎると混乱するし、非常に多くのエラー処理メカニズムがあると少しめまいがすることもあります。 J2EE 分野でのエラー処理を比較すると、比較的単純であることがわかります。 1 つ目は、<customErrors> に対応する設定です。J2EE プロジェクトで最もよく使用される web.xml ファイルからも同様の設定項目が見つかります。2 つ目は、J2EE の分野では、Page は重要なエンティティではありません。イベント ドライバー モデルは必要ないため、Application_Error メソッドと Page_Error メソッドに対応する処理メカニズムが見つかりません。最終的に、J2EE の分野では、論理処理でエラーが発生した場合に重点が置かれます。 , 実際、これは非常に柔軟な処理方法なので、興味のある方はぜひ学んでみてください。