この質問は、ASP.NET要求のライフサイクル中に発生する例外を最適に処理する方法に関するものであるという点で、ASP.NETでのURIハッキングの処理に関連しています。ほとんどの例外を適切に処理する方法を見つけましたが、リクエストの後半にいくつかの例外が発生するため、Server.Transfer
エラープレゼンテーションロジック全体を独自のページにコンパートメント化するような方法がないことがわかりました。
したがって、Application_Error
代わりにイベント内で例外を処理し、 Response.Write
sなどを実行する必要があります。それは醜いです。状況によっては、応答ストリームがすでにフラッシュされている可能性があることを理解しています。そのため、要求を転送することは実際にはオプションではありません。私が聞きたいのは、この問題のエレガントな解決策を見つけた人がいるかどうかです。
また、リクエストを別のページに転送することで例外を適切に処理できるかどうかを知るのは難しいと思います。例外が発生したときにリクエストライフサイクルのどこにいるかを知るための最良の方法は何ですか?ページの読み込みとレンダリング中に発生した場合は、Page_Error
それを処理できるようになりますが、まだ問題はServer.Transfer
ありません。しかし、例外が発生するのが早すぎるか遅すぎるためPage_Error
にキャッチできず、バブルが発生した場合、Application_Error
それが早いか遅いかを知るにはどうすればよいですか?
ライフサイクルが遅い場合は、Response.Write
から直接実行する必要がありますApplication_Error
が、早い場合は実行できますServer.Transfer
。問題は、Server.Transfer
それが要求に含まれている場合、それ自体が例外を引き起こすことです。
それで、応答で創造的なことをするのに遅すぎるかどうかを示すグローバルな列挙または同様のものはありますか?