私はASP.NET Webアプリケーションを開発中です。私は、アプリケーション全体のロギングフレームワークを実装しています。ASP.NETの一般的なエラーページのベストプラクティス
ウェブアプリケーションは約7-8ページあり、簡単なCRUD操作Webアプリケーションです。
そのAzureホストアプリケーション。以下は、私がロギングと例外処理に従っているアプローチです。
1）Try ... Data Access LayerおよびClickイベントにブロックを追加しました。
2）エラーが発生すると、Globabl.asaxレベルまで例外を伝播し、Application_Errorイベントでエラーをイベントログとトレースログに記録します。
3）これをGlobal.asaxファイルに書き込んだ後、エラーページにリダイレクトして、ユーザーフレンドリなメッセージを表示し、失敗したページにリンクします。
4）これを行うには良いアプローチであるかどうかを知りたかっただけです。
ありがとうございました。
なぜASP.NETカスタムエラーページを使用しないのですか？ステータスコードごとにエラーページを指定することも、デフォルトのリダイレクトを指定することもできます。
これはWeb設定で設定することができ、すべて設定されています。
<customErrors defaultRedirect="GenericError.htm" mode="On">
<error statusCode="404" redirect="notfound.htm"/>
</customErrors>
あなたはすべてのユーザーにのみ、リモートユーザーなどにカスタムエラーページを表示するためにそれを設定することができます。..
http://aspnetresources.com/articles/CustomErrorPages
私は完全にあなたのcatchブロックですべてのエラーをログに記録する必要があることに同意それをログに書き出します。
実際にDALで例外を処理していますか（つまり、ログ記録、修正しようとしていますかなど）？そうでなければ、try catchはスピンサイクル以外の目的を果たしません。クリックイベントでも同じことが当てはまりますが、実際に何もしていなくても、UIのエラーを処理することは悪いことではありません。ユーザーを醜いエラーページから自分のフレンドリーなメッセージに誘導します。
本当に例外がスローされた場合には、単一のエラーページが正常に動作します。あなたが醜いメッセージを表示するのを避けるために、貴重な小さなコードを書いていくことで、市場投入までの時間が短縮されます。欠点は、ユーザがコンテキストを逃していることです。私は本当に1つのサイズですべての例外ハンドラに適合していません、バックアップ以外（私は私の最初の行ハンドラを過ぎている想像していないエラーがあります）。
HTTPステータスに基づいて処理し、configを使用する場合は、一般的なエラーページのバリエーションがあります。
別のパターンは、独自のベースページを設定し、エラーハンドラとして機能させることです。次に、エラーが発生したときに入力するコンテナを脇に置くことができます。このアプローチはコンテキストの追加にはうまくいきます。ユーザーはまだページの一部を見ていますが、エラーメッセージが表示されているので、失敗したことが分かります。このパターンは、エラーが発生したときにコンテナに追加されたユーザコントロールで使用されていますが、表示するコードのテーブルと適切なメッセージを設定する必要があるため、もう少し呼び出されます（バグの可能性がありますそれ自体の）。
ここでホイールを再発明しているようですね。 ASP。NETには既に目的の結果を達成するためのものが含まれています。エラー後にクリーンアップするロジックを処理する必要がない限り、try catchブロックは使用しません。ログエラーのためにASP.NET Health Monitoring Overviewを見てください。カスタムエラーページを表示する限り、How to create custom error reporting pages in ASP.NET by using Visual C# .NETを参照してください。
私は、例外処理を使用する必要はないと思います。プレゼンテーション層とビジネスロジック層/データアクセス層があるとします。
Business Logicのエラーに直面すると、Application_Errorイベントの下で直接Glogal.asax.csファイルに移動し、呼び出し元の関数に戻ることはありません。ここでは、
HttpContext.Current.Server.GetLastError().InnerException.StackTrace
HttpContext.Current.Server.GetLastError().InnerException.Message
HttpContext.Current.Server.GetLastError().InnerException.Source
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.FullName
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Name
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Namespace
は今のWeb Configであなたは以下のようないくつかのデフォルトページにユーザーをリダイレクトするコードを書くことができます....以下のようなエラーメッセージをログに記録することができます。
<customErrors defaultRedirect="ErrorPage.htm" mode="On">
<error statusCode="404" redirect="ErrorPageNotFound.htm"/>
</customErrors>
いいえ、私はすべての標準400+と500+エラーについては試していませんが、私はASP.NETのカスタムエラーページを使用しています。ただし、そうでない場合はDB接続がタイムアウトになります。データアクセスレイヤーにキャッチを持っていれば、そこで発生している興奮を知ることができます。 – sqlnewbie
DBExceptionのようなカスタム例外を実装し、Global.asaxレベルまでスローしました。タイプに基づいて、サーバーのDB接続に関するいくつかの問題を示すユーザーにメッセージを表示します。管理者に知らせてください。 Clickイベントに何か問題がある場合は、入力に関する問題を解決します。もう一度お試しいただくか、管理者にお問い合わせください。 これは良いアプローチですか？ – sqlnewbie
例外に関する追加情報を伝えている場合は、カスタム例外に例外をラップすることは完全に容認された方法です。しかし、ユーザはなぜそれが失敗したのかを知る必要はなく、そのことを伝えるべきではない。ユーザーと直接対話したことがある場合は、メッセージが何と言っているかを常に忘れていることがわかります。だからこそ私は標準的なエラーページとヘルスモニタリングを提案します。エラーの詳細をログに記録するようにヘルスモニタリングを設定できます。また、例外が発生したときに電子メールを送信するようにヘルスモニタリングを設定することもできます。 – JamieSee