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

Question

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

Answer 1

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

我通过使用throw关键字重新抛出异常，并且不向用户显示异常只显示错误消息并使用LOG4NET记录异常，或者在文件中找到您容易找到的方式。

您可以查看此帖子如何在不隐藏详细信息的情况下抛出异常：Handle Exception Carefully

Answer 2

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

 int doSomeThing( ... ) throws Some exceptions

异常可能是显式的，如在Java的Checked Exceptions中，或者是隐式的。然而，调用者必须预测异常并决定做什么 - 有时候一个方法可能决定只允许异常传播，你调用的异常会成为正式接口的一部分。

我的方法：

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

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

• 业务逻辑层暂时无法为您的请求提供服务（例如，DB已关闭），我在此标题中包含了意外的空指针等，它们是由编码错误引起的，但它们在业务层
• 您，客户先生，无权执行此操作
• 您的请求无效，违反了一些商业逻辑规则（不能为新劳斯莱斯指定一个斗牛士附件）

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

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

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

业务逻辑层负责从较低层捕获无数问题并为UI生成例外。

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

Answer 3

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

请参阅此帖子Exception handling

Answer 4

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

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

Try
{

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

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