这个问题与Handle URI hacking gracefully in ASP.NET有关,因为它太关于如何最好地处理在ASP.NET请求生命周期中发生的异常。我找到了一种方法来优雅地处理大多数异常,但后来发现在请求中发生了一些异常,因此无法像Server.Transfer
那样将整个错误表示逻辑划分到它自己的页面中。如何在ASP.NET请求生命周期中处理异常
因此,我必须处理Application_Error
事件中的异常,而不是Response.Write
和什么。它很丑。我知道在某些情况下,响应流可能已经被刷新,因此传输请求并不是真正的选择。我想问的是,是否有人找到了解决此问题的优雅解决方案?
此外,我发现很难知道什么时候可以通过将请求转移到另一个页面而不是正常处理异常。发现异常时,找出我们所处的请求生命周期中的哪个位置的最佳方法是什么?如果它在加载和呈现页面期间发生,Page_Error
将能够处理它,并且在那里我还没有遇到问题Server.Transfer
。但是,如果Page_Error
发现异常发生时间太早或太迟而无法捕捉到,并且它会冒泡到Application_Error
,我该怎么做才能知道它是早期还是晚期?
如果它在生命周期的后期,我可能必须直接从Application_Error
做Response.Write
,但如果它提前,我可以做Server.Transfer
。问题是试图做Server.Transfer
本身会导致一个异常,如果它太请求执行它。
那么,是否有一个全球性的枚举或类似的东西,表明是否已经太迟了,以创造性的东西与答复或不?
嗨,谢谢你的建议。 外部控制台应用程序不会真的帮助,因为我想要的不仅是捕捉错误(我已经做得很好),而且还显示友好的错误消息。 – 2009-02-27 11:44:57
您使用的是自定义错误页面吗?这使您可以基于任何基于任何请求结果抛出的Http状态码来显示自定义信息? – 2009-02-27 12:05:15