2

バックグラウンド

例外処理のために MVC Web アプリに[HandleError]を配置しましたが、後でいくつかの例外を処理できなかったため、別のApplication_Error (私の SO Post ) に進むように提案されました。

まあ、ELMAHはロックです!しかし、フォーマットされた例外を表示する方法を見つけることができませんでした (Application_Error の場合と同様)。

ELMAH v/s Application_Error

ELMAH - (ほぼ) すぐに使える例外ログや電子メールなどのその他の機能を提供します. web.config とそれに必要な一連のファイルに完全に依存しています。例外を xml / データベース (構成に従って) に記録でき、電子メール、RSS などに対応できます。ユーザーが完全な例外ログを表示し、詳細をドリルダウンできるページを提供します。

長所:エラー時にフォーマットされた例外を表示しません。web.config が少しかさばります。ELMAH ファイルのセットは 2.8 MB です (Web アプリの zip 全体のサイズの 2 倍以上)。エラー/メールをフォーマットできません。CPUアーキテクチャに依存するSystem.Data.SQLite.dllに依存しています(x64またはx86)SOポスト

Application_Error - すべての例外をキャッチし、ユーザーをナビゲートしてフォーマットされたエラーを表示できます。何が表示され、電子メールで送信されるかを制御します。完全に管理されたコード (CPU に依存しない) で、余分な web.config 設定はありません。余分な dll はありません。

長所:暗黙の例外ログがありません (コーディングする必要があります)。ELMAH のようなログ ビューアーはありません。メール、ログ - すべてを管理する必要があります。

結論: まず、ELMAH が私の Application_Error を「完全に」置き換えることができるかどうか教えてください。また、ELMAH で表示または電子メールで送信されるエラー メッセージを構成する方法についても、あまり見つけられませんでした。または、共存する必要がありますか (フォーマットされたエラーを表示する Application_Error と、他のほとんどすべての ELMAH を表示する)。

あなたの経験を提案し、共有してください。

4

1 に答える 1

0

私はELMAHと一緒に暮らすことができます(フォーマットされた例外の詳細をユーザーに表示することを除いて-または少なくとも私はそれについて何も見つけられませんでした)

SOの聴衆を引き付けるために私の投稿に何が欠けていたのだろうか. 私は自分のスレッドに Atif 自身から回答をもらいました - より速く、より簡単に!

https://groups.google.com/forum/?fromgroups=#!topic/elmah/Md9DslGgwNo

于 2012-09-19T15:21:28.007 に答える