8

私は最近、コントローラーで例外を処理する際に一貫性があまりないasp.net mvcプロジェクトに参加しました。一部の開発者はデータをクライアントに返してユーザーに何が問題なのかを知らせますが、他の開発者はデータをスローして処理し、ログに記録するサーバーレベルのハンドラーに到達します。

どちらのアプローチもそれ自体が間違っており、代わりに相互に補完する必要があることは明らかです。私が立ち往生しているのは、それを行う方法です。最終的な例外ハンドラー/ロガーは、特に厄介なものをキャッチするとユーザーをエラーWebページにリダイレクトできると思いますが、それはメカニズムを深刻なものに限定します.

例外をキャッチしたときに「スロー」と「リターン...」の両方を行う方法を探しているので、サーバー側でソートしてログに記録し、クライアント側でデータを取得して、ユーザー しゃっくりがありました。

asp.net に関する私の専門知識は非常に限られており、問題にならない程度に mvc を十分に理解していると思いますが、これは一種の「ベスト プラクティスとは何か?」ということです。ベストプラクティスをあまり気にしない人々と一緒に働いている人からの質問。

4

2 に答える 2

2

ASP.NET アプリケーションでエラーと例外をログに記録するための Elmah という優れたプロジェクトがあります。ここで見つけることができます

ELMAH (Error Logging Modules and Handlers) は、完全にプラグ可能なアプリケーション全体のエラー ログ機能です。実行中の ASP.NET Web アプリケーション、またはマシン上のすべての ASP.NET Web アプリケーションに動的に追加でき、再コンパイルや再展開は必要ありません。

ELMAH を実行中の Web アプリケーションにドロップして適切に構成すると、コードを 1 行も変更せずに次の機能を利用できます。

  • ほぼすべての未処理の例外のログ。
  • 記録された例外のログ全体をリモートで表示する Web ページ。
  • ログに記録された 1 つの例外の完全な詳細 (色付きのスタック トレースを含む) をリモートで表示するための Web ページ。
  • 多くの場合、customErrors モードをオフにしても、特定の例外に対して ASP.NET が生成した元のイエロー スクリーンを確認できます。
  • エラー発生時の各エラーの電子メール通知。
  • ログからの最後の 15 個のエラーの RSS フィード。
于 2012-04-10T12:08:18.237 に答える
0

私が取り組んでいる MVC アプリケーションは、アプリケーションからスローされた例外を処理するために を実装しApplication_Error、Global.asaxユーザーを標準エラー ページにリダイレクトします。エラー ページのコントローラは、ログを処理するだけでなく、サポート担当者がシステム内のセッションを見つけて問題を解決できるように、エラーに関する十分な情報を表示します。

于 2012-04-10T12:10:53.897 に答える