1）据我所知，在three-tier Asp.Net应用程序中，我们应该通过以下方式实现异常处理：
a - 我们应该将try-catch块放在代码块（位于三层中的任何一层）中，我们期望从中优雅地恢复页面（当此代码生成异常时）？
b - 我们不应该在代码（位于三个层中的任何一个）中放置try-catch块，我们不希望从中优雅地恢复页面。相反，Asp.Net应用程序应始终通过全局异常处理程序（Application_Error/Page_Error）管理这些未处理的异常？
2）通过Ap plication_Error/Page_Error管理未处理的异常的主要好处是这样我们将错误处理集中在一个位置的事实？
毕竟，我们可以实现相同的结果，即使这些未处理的异常（在三个层中的任何一个中抛出）在它们被抛出的地方被处理（记录，用户重定向到自定义错误页面...）？ ！
谢谢
答案 0 :(得分：2)
不一定。
1a - 数据层没有异常处理是完全可以接受的。在这种情况下，任何异常都将在堆栈中进一步处理。
1b - 可能无法通过网站调用数据层和业务层，因此特定网页不一定相关。例如，Web服务或WPF应用程序也可以使用这些层。
2 - 是的，主要好处是网站错误处理的单一位置。
答案 1 :(得分：2)
您要避免的主要问题是无声地吞咽无法恢复的异常。 （简而言之，有一个try...catch块，你向用户显示一些错误，但不要重新抛出异常，因此只有最终用户知道出现了问题。）
如果发生异常并且您可以从中恢复，那太好了！
如果发生异常并且无法从中恢复，则记录异常详细信息并向开发人员通知异常非常重要。通常，这是通过让异常传播到ASP.NET运行时层来完成的，这样ASP.NET的Error事件就会触发。最佳做法是以某种方式订阅此Error事件，以便记录错误详细信息并通知开发人员。面向错误时记录和通知的一个此类工具是ELMAH，另一个是ASP.NET Health Monitoring库。
另外，如果可以的话，我会建议我的这篇文章，其中更详细地介绍了我在这里提出的观点：Exception Handling Advice for ASP.NET Web Applications。
快乐编程！
答案 2 :(得分：1)
1a）是正确的。 1b）有点正确;您可以让异常从模型/业务层到堆栈上升，并显示错误消息。它不必一直到Application_Error; Page_Error可能很好，但是一些异常可能（相对）足够常见，虽然你无法正常恢复，但在某些情况下你应该有与它们相关的特定错误消息。
基本上是; 2）而且，对于您无法预测和捕获更多特定地点的例外情况，“全部捕获”。