三层Asp.Net应用程序中的异常处理

Question

1)据我所知，在three-tier Asp.Net应用程序中，我们应该通过以下方式实现异常处理：

A-我们应该在代码块(位于三层中的任何一层中)周围放置try-catch块，我们希望页面从这些代码块中优雅地恢复(当此代码生成异常时)？

B-我们不应该把try-catch块放在代码周围(位于三层中的任何一层)，因为我们不希望页面从容地恢复过来。相反，Asp.Net应用程序应该始终通过全局异常处理程序( Application_Error/Page_Error )来管理这些未处理异常？

2)通过Application_Error/Page_Error管理未处理异常的主要好处是这样的事实，即我们将错误处理集中在一个位置？

毕竟，即使这些未处理的异常(在三层中的任何一层中抛出)被处理(记录日志，用户重定向到自定义错误页面... )，我们也可以获得相同的结果。在他们被扔的地方？！

谢谢

Answer 1

1a)是正确的。1b)在某种程度上是正确的；您可以让异常从模型/业务层向上堆栈到表示层，并显示一条错误消息。它不一定要一直到Application_Error；Page_Error可能是好的，但一些异常可能(相对)常见，虽然您不能正常恢复，但在某些上下文中应该有与它们相关的特定错误消息。

2)基本上；而且作为异常的“全部捕获”，您无法在更具体的地方预测和捕获。

Answer 2

不一定。

1a -数据层没有异常处理是可以接受的。在这种情况下，任何异常都将在堆栈的更高位置处理。

1b -数据层和业务层可能不会通过网站调用，因此特定的网页不一定相关。例如，webservice或WPF应用程序也可以使用这些层。

2-是的，主要的好处是网站错误处理的单一位置。

Answer 3

您要避免的主要问题是默默地接受无法恢复的异常。(简而言之，在try...catch块中，您可以向用户显示一些错误，但不要重新抛出异常，因此只有最终用户才知道出了问题。)

如果发生异常，并且您可以从中恢复，那就太好了！

如果发生异常并且无法恢复，那么重要的是记录异常详细信息，并将异常通知给开发人员。通常，这是通过让异常传播到ASP.NET运行时层，以便ASP.NET的Error事件将被激发来完成的。最好以某种方式订阅此Error事件，以便记录错误详细信息并通知开发人员。一种这样的工具是ELMAH，另一种是ASP.NET Health Monitoring库，用于在出现错误时记录和通知。

另外，如果可以的话，我推荐我的这篇文章，这篇文章涵盖了我在这里提出的更深入和详细的观点：Exception Handling Advice for ASP.NET Web Applications。

祝您编程愉快！