Web アプリケーションの場合、エラーは避けられないため、予防策を講じ、発生する可能性のあるエラーに適切に対処する必要があります。実際、優れたエラー処理メカニズムは、Web アプリケーションの品質を測定するための重要な基準です。想像してみてください。ユーザーが誤ってブラウザに間違った URL を入力した場合、またはユーザーがプログラムにエラーを引き起こす情報を入力した場合、これらの状況に対処しなければ、404 または 500 のエラー ページ、さらにはスタック情報が発生する可能性があります。がユーザーの目の前に提示されると、一部のユーザーは間違いなく怖がってしまいます。したがって、Web アプリケーションを開発するときは、エラー処理メカニズムを完全に理解する必要があります。
ASP.NET に戻って、誰もが考えられる 2 つの質問をしてみましょう。ASP.NET には、エラー処理メカニズムがいくつ提供されていますか?複数のエラー処理メカニズムが同時に使用される場合、それらの間に特定の優先順位はありますか?この質問を念頭に置いて、まず最も一般的な Web.Config ファイルを見てみましょう:
<構成>
<システム.ウェブ>
次に、同じく非常によく使用される別のファイルである 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 つの具体的な例を示します。
protected void Page_Error(オブジェクト送信者, EventArgs e) {
例外 objErr = Server.GetLastError().GetBaseException();
Response.Write("エラー:" + objErr.Message);
Server.ClearError(); //このコードの使用にも注意してください
この
時点で、4 つのエラー処理メカニズムがすべて登場したので、それらをランク付けします。優先度の高いものから低いものへと並べ替えます: Page_Error イベント処理メソッド > ErrorPage プロパティ > Application_Error イベント処理メソッド >
さて、ASP.NET の 4 つのエラー処理メカニズムの紹介はこれで終わりです。ここからは私自身の感じたことをいくつか話していきます。 ASP.NET の設計者は開発者の観点から徹底的に検討しており、選択できるエラー処理メカニズムを 4 つも提供しており、これは賞賛に値します。しかし、広告のスローガンを言い換えると、多すぎると混乱するし、非常に多くのエラー処理メカニズムがあると少しめまいがすることもあります。 J2EE 分野でのエラー処理を比較すると、比較的単純であることがわかります。 1 つ目は、