ASP.NETエラー処理

Question

私のasp.netアプリケーションでは、通常、Application_Errorグローバルイベントハンドラを使用してエラーを記録し、ユーザーフレンドリなエラーページにリダイレクトしました。

しかし、私はELMAHについて読んでいますが、面白そうですが、Application_Errorは簡単なアプローチのようです。

自分自身を含む人々がどちらか一方の方法を示唆している他の質問を読んだことがあります。私が疑問に思っているのは、他のものを使用することに大きな利点があるのはなぜですか、なぜですか？

Answer 1

Elmahはすばらしいプロジェクトです。私たちはすべてのASP.NETアプリケーションにこのプロジェクトを使用しています。あなたのために処理されていないエラーを記録するだけでなく、オリジナルのページを取得します。このページには多くの詳細が含まれています。

電子メールサポート、RSSフィード（アイテム化とダイジェストの両方）があり、魅力的なコンソールがあります。

3行の設定とdllの参照については、それはスラムダンクだと思います。

Answer 2

私はELMAHの主な欠点は、あなたが必要とするものが過度であるかもしれないということです。ロギングして、独自の実装よりも多くの情報を格納する場合、ストレージと処理の不必要なオーバーヘッドです。 ELMAHのコンソールへのアクセスをどのように保護するかについて考える必要があります。例外の詳細には、アプリのジューシーな詳細が含まれる可能性があるからです（これは難しいことではありませんが、以前はなかった心配です）。

一方、頑固なバグが必要であると判断したら、追加の情報をすべてログに記録するようになります。実際には、エラーページが表示されますか？最終的にELMAHの独自のバージョンを構築する可能性がありますので、ELMAHを使用して時間を節約してみませんか？

ELMAHを使用するのではなく独自のエラーログを書きたい場合は、少なくともglobal.asaxのApplication_Errorではなく、モジュールに入れておくことをお勧めします。モジュールのInitメソッドでアプリケーションのErrorイベントを登録するだけで、エラー処理コードを別のアプリケーションでweb.configの行で簡単に再利用できます。

ASP.NETの正常性監視を通じて例外ログを処理すると便利です。これにより、web.configのログのタイプとレベルを簡単に制御できます。また、Application_Errorまで取得せずにtry ... catchで処理された例外のログを記録することもできます。 WebRequestErrorEventを継承するカスタムのHandledExceptionEventクラスを作成し、処理されたにもかかわらず例外が発生したことを本当に知りたいキャッチブロックでイベントを作成して呼び出すことができます。