当使用DAL、BLL和web表示层时，我应该捕捉哪些层的异常

本文关键字：我应该 异常 DAL BLL 表示层 web | 更新日期: 2023-09-27 18:05:05

我写了一个三层web应用程序。DAL BLL和web表示层，每层都有方法，所以问题是我应该在哪里捕获异常(使用try catch)，在web?BLL?还是木豆?,为什么?谢谢你。

当使用DAL、BLL和web表示层时，我应该捕捉哪些层的异常

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

 int doSomeThing( ... ) throws Some exceptions

异常可以是显式的(如Java的受控异常)，也可以是隐式的。尽管如此，调用者必须预测异常并决定做什么——有时一个方法可能决定只允许异常传播，来自你调用的东西的异常成为你正式接口的一部分。

我的方法:

  1. 每一层应该封装它的实现细节;特别是终端用户不应该看到技术错误信息
  2. 健壮的应用程序必须记录错误症状才能进行问题诊断

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

  • 业务逻辑层暂时不能处理您的请求(例如:DB down)，我在这个标题中包含了意想不到的，空指针等，它们是由编码错误引起的，但它们在业务层
    • 中得到了修复
  • 您，客户先生，无权这样做
  • 您的请求无效，它违反了某些业务逻辑规则(不，您不能为您的新劳斯莱斯指定推土机附件)

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

InvalidRequestException倾向于有有用的有效负载来帮助UI格式化有用的响应。

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

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

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

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

我通过使用throw关键字重新抛出异常，不向用户显示异常，只是使用LOG4NET或在文件中显示错误消息和日志异常。

你可以查看这篇文章如何抛出异常而不隐藏细节:小心处理异常

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

异常处理

Pranay Rana给出的链接描述了从层传播异常的正确方法，但是，除非您需要对异常采取一些行动，否则没有必要在底层(DAL, BAL)中扭曲try catch中的方法。

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

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

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

相关文章：