使用 DAL BLL 和 Web 表示层时我应该捕获哪些层的异常

Question

我编写了一个三层 Web 应用程序。 DAL BLL和Web表示层，每一层都有方法，所以问题是我应该在哪里捕获异常（使用try catch），在web？BLL？还是DAL？为什么？谢谢。

Answer 1

异常是任何方法接口的一部分。

 int doSomeThing( ... ) throws Some exceptions

异常可以是显式的（如 Java 的受检查异常），也可以是隐式的。尽管如此，调用者必须预见异常并决定做什么 - 有时一个方法可能决定只允许异常传播，您调用的事物的异常成为正式接口的一部分。

我的做法：

1. 每一层都应该封装其实现细节；特别是最终用户不应该看到技术错误消息
2. 强大的应用程序必须记录错误症状以进行问题诊断

因此，在 Web/表示层中，我们捕获所有异常并向用户显示友好的消息。往往有少数常见的场景：

• 业务逻辑层暂时无法服务你的请求（例如DB宕机），我在这个标题中包含了意外的、空指针等，它们是由编码错误引起的，但它们在业务层中进行了补救
• 您，客户先生，无权这样做
• 您的请求无效，它违反了某些业务逻辑规则（不，您不能为您的新劳斯莱斯指定推土机附件）

我发现UI有时会显示错误信息在这些情况下有所不同，因此我喜欢区分它们。这导致我设计我的业务逻辑接口来抛出相应的异常：TransientException、AuthorizationException、InvalidRequestException。

InvalidRequestException 往往具有有用的负载来帮助 UI 格式化有用的响应。

TransientException 可以包含技术信息（例如 DB XXX 有问题 YYY），不是为了向用户显示，而是作为分布式系统中诊断的辅助。

业务逻辑层负责捕获来自下层的无数问题并为 UI 生成异常。

数据访问层应遵循首次失败数据捕获的原则：捕获问题详细记录错误并抛出一些合适的异常。

Answer 2

最好在数据库层捕获异常并将其抛出到业务层，而不是从业务层抛出到表示层。

我使用 throw 关键字重新抛出异常，并且不向用户显示异常，只是使用 LOG4NET 或在文件中显示错误消息和日志异常，您会发现这种方式对您来说很容易。

您可以查看这篇文章如何在不隐藏详细信息的情况下抛出异常：仔细处理异常

Answer 3

除非您确定要处理错误，否则不要在所有方法中使用 try catch。您可能可以在 DAL 中使用 catch ，记录异常并将其抛出到该层。

请参阅这篇文章异常处理

Answer 4

Pranay Rana 给出的链接描述了从层传播异常的正确方法，但是，没有必要在底层（DAL、BAL）中的 try catch 中扭曲方法，除非您需要对异常采取一些操作。

当退出方法之前必须执行某些代码段时，将方法包装在 try catch 中，例如在退出之前清理 SQL 连接/资源。扭曲你的方法，例如

Try
{

}
Catch
{
throw;
}
finally
{
//Mandatory code segment
}

确保将调用（在 UI 或任何其他层中）包装在 try catch 中。即使方法没有包装在底层的 try catch 中，异常也会在调用点被捕获。