5

私は、例外処理システムを書き直すというスリル満点の仕事を与えられました。アプリケーション全体の観点から例外を処理することは私たちが望んでいるものではないと述べますが、通常、ドアを押し出す必要がある膨大な量の作業のためにチームの人員が不足している場合、それは避けられません。ここでの例外処理のグローバル化されたソリューション:)

どのような一般的な解決策が存在するかをよく調べました。現時点では、Application_Error イベントで Global.asax を使用して Server.GetLastError() を実行します。これは Session 状態に置かれ、リダイレクトが別のページに呼び出され、そこでセッション データが取得され、人間が判読できる形式で出力されます。リダイレクトは、a) 開発者に電子メールで送信され、b) 開発者のみが表示できる Web ページから表示されたエラー情報を慎重に監査する sproc も呼び出します。

私が見た新しい方法は、App_Code のクラスを使用して IHttpModule インターフェイスを使用して、これらの行に沿って何かを行うことです (これは私の簡単な実装です)。

Imports Microsoft.VisualBasic

Public Class ErrorModule : Implements IHttpModule

  Public Sub Dispose() Implements System.Web.IHttpModule.Dispose
    ' Not used
  End Sub

  Public Sub Init(ByVal context As System.Web.HttpApplication) Implements System.Web.IHttpModule.Init
    AddHandler context.Error, AddressOf context_Error
  End Sub

  Public Sub context_Error(ByVal sender As Object, ByVal e As EventArgs)
    Dim ex As Exception = HttpContext.Current.Server.GetLastError

    ' do something with the error
    ' call the stored procedure
    ' redirect the user to the error page

    HttpContext.Current.Server.ClearError()
    HttpContext.Current.Response.Redirect("index.htm")

  End Sub
End Class

私の質問は、Global.asax イベントの使用に対するこのソリューションの利点は何ですか? また、データをエラー ページに渡す最善の方法は何ですか?

EDIT：上記のコードは、ところで動作します;）

編集:また、HttpModule は舞台裏でどのように機能しますか? アプリケーションの起動時にその特定の関数にエラーイベントを登録するだけですか?

アップデート：

さらに詳しく調査すると、IHttpModule インターフェイスの使用に関しては、セッション データの取得が非常に厄介なようです。MS は、特定のシナリオで使用できるほど十分に HttpModule を成熟させたとは思いません。セッション データに固有のイベントが発生するまでは、危険すぎて使用できません。

4

2 に答える 2

7

モジュールを使用すると、簡単に削除できるという利点があります。無効にするには、構成の <httpModules> からモジュールを削除するだけです。

データに関する限り、Server.TransferまたはServer.RewritePathを使用してみてください。これにより、現在のすべてのデータ (最後のサーバー エラーを含む) が保持されます。

何らかの理由で最後のエラーがクリアされた場合は、転送/書き換えの前にエラーをHttpContext.Itemsに保存し、後で取得できます。

編集:編集に応じて、IHttpModule はIHttpModule.Init実装の適切なイベントにアタッチされます。

于 2009-03-04T13:34:33.960 に答える
1

HttpModule基本的に と同じことを行いGlobal.asaxます。イベント処理のための、より再利用可能で自己完結型のモジュールとして設計されています。

于 2009-03-04T13:33:50.517 に答える