我应该在global.asax中捕获所有异常吗？

Question

如果我只是在我的网络应用程序中记录异常详细信息，我是否真的需要为每个层添加异常处理逻辑？为什么不让它们将堆栈跟踪冒泡到global.asax并将它们记录在那里？

Answer 1

我建议不要在应用程序的任何层使用任何异常处理逻辑，除非：

• 例外不是致命的，这意味着你可以采取一些行动来恢复，或
• 应用程序应继续运行，异常应“被忽略”。例如：在在线零售商处结账时，您会通过电子邮件发送收据。如果失败 - 但其他订单处理成功 - 则不应向用户显示错误页面。在这里，我们希望即使存在异常，工作流也会继续。大多数例外都不属于这一类。

当然，例外 - 无论是否致命或应该被“忽略” - 都需要记录并通知开发人员。最好通过Application.Error事件的事件处理程序来处理。是的，这可以在Global.asax中完成，但我认为使用基于HTTP模块的方法（Health Monitoring或ELMAH更清晰。

我已经写了一篇关于这个主题的文章，我想向你推荐 - Exception Handling Advice for ASP.NET Web Applications。以下是摘要中的文章：

  

我在ASP.NET应用程序中处理异常的建议可以归结为以下准则：

     

（a）创建并使用有意义的自定义错误页面。

     

（b）一般而言，不要捕捉例外情况。让它们冒泡到ASP.NET运行时。捕获异常的一些情况包括：

     

  

• 当有合理的方法通过执行某种替代逻辑从异常中恢复时，

  

• 当应用程序的工作流程的外围部分抛出异常并且异常不应该使整个应用程序脱轨时，

  

• 当您需要通过抛出一个将原始异常作为其内部异常的新异常时，在异常中包含其他信息。

  

     

（c）将所有异常记录到某些持久性存储中，并使用电子邮件（或其他一些介质）在生产中发生异常时通知开发人员。考虑使用ELMAH或ASP.NET的内置运行状况监控系统来促进此过程。

Answer 2

异常应该冒泡到任何层可以以有意义的方式处理它们，并且知道Single Responsibility principle。例如，您的数据层不应投入日志记录。

Application.Error事件是catch-all错误处理的好地方：即意外和/或致命错误，除了记录/警告和重定向到错误页面之外不需要特殊处理。

Answer 3

如果您的网络应用程序使用Microsoft AJAX扩展和部分回发，您至少需要在两个地方处理异常：

1. Global.asax中
2. 您的ScriptManager的OnAsyncPostBackError处理程序

有关OnAsyncPostBackError的更多信息，请查看：

http://msforge.net/blogs/janko/archive/2008/02/13/handling-exceptions-in-asp-net-ajax.aspx

http://msdn.microsoft.com/en-us/library/system.web.ui.scriptmanager.onasyncpostbackerror.aspx

Answer 4

我说全球尝试抓住您错过的程序逻辑步骤错误，并将其重定向到“错误页面”或“未找到的页面”。

所有其他不必要的错误都会显示用户的错误，而不需要将其发送到错误页面。

例如，在包含2个或更多不同模块的页面中，如果一个错误，只需隐藏它，然后显示其余模块。类似的尝试在它们发生时捕获错误并在可能的情况下以最佳的非可视方式处理它们，记录它们并在以后更正它们。

现在这个错误只发生在一个模块上，您可以在日志中看到并更正它，但在您这样做之前，用户会在您的页面上看到一些内容，而不是完整的错误页面。

Answer 5

通常我做的是尝试...捕获代码，但不是登录捕获我所做的是传递它，并在消息中说明错误来自哪里等等。然后我使用Elmah来捕获所有错误并记录它们。

这样，您只需处理一个区域中的日志记录并满足单一责任原则，但您可以获得更多可用于调试目的的信息。当您获得仅在500个用户中有1个出现的数据错误时，它也会很有用。