java - 异常设计——每一层的自定义异常

Question

在我们的系统设计中，我们有以下几层:

Web API -> BusinessLayer -> HelperLayer -> DataLayer - Call hierarchy

Web API是Rest服务层，Business对业务实体进行业务操作，Helper进行Data实体到业务实体的转换，Data从数据库中获取POCO

在讨论系统的异常管理策略时，有以下两种观点:

我更喜欢所有错误都传播到 Web API，我们在 Web API 中使用错误过滤器来拦截、记录错误并更改 Context.Response 以向最终用户提供友好的消息，相同的好处是:

1. 错误源保持不变

2. 我们在需要时处理异常

3. 简单直接的错误处理机制

另一组团队成员更喜欢我们为每一层创建一个自定义异常，如 DALException、HelperException、BusinessException，其中给定层抛出异常，调用层处理它，填充内部异常，然后继续，按照他们的好处是:

1. 每一层都可以提供问题/异常的自定义信息，这有助于错误/异常的抽象

对我来说，这个设计的问题是:

1. 更改异常源不是一个好的做法
2. 捕获异常而不做任何处理
3. 通过在各处添加 try catch 来编写大量额外代码，据我所知，这会影响性能

我看到的唯一好处是我们可以向客户提供特定消息，但如果我们了解底层核心异常并根据某些代码进行区分，从而提供自定义消息(如 ABC 失败)而不是通用消息，那甚至是可能的.

请分享您的观点，如果需要澄清，请告诉我

Answer 1

我建议通过使用拦截器而不是将任何逻辑直接放在您的类和方法中来(某种程度上)避免这个问题。

如果一个类的职责是接收对某些数据的请求并从 SQL 返回它，那么它不应该关心哪些层期望哪些类型的异常。该异常处理成为该类职责之外的附加逻辑。

有许多不同的方法可以实现拦截。这可能取决于您的应用程序中已经包含了哪些工具。我用 Windsor用于依赖注入(inject)，因此使用它们的拦截器很方便。如果我不使用 Windsor，那么我会查看 PostSharp .

但最终的结果是你要么在你的类上有一个属性，要么在你声明你的依赖项时有一个声明，然后所有的逻辑都是“抛出这种类型的异常，捕获它，包装它等等，然后重新-throw”所有生命都在拦截器类中。您可以来回更改它而不会污染您的其他类。

99% 的情况下，这使我的代码中完全没有 try/catch block 。记录和重新抛出被降级到拦截器。唯一一次我有任何异常处理是如果我需要优雅地处理一些东西，所以我需要捕获异常，记录它，并返回一个非异常结果。

---

与拦截无关:

在实践中，我发现大多数情况下，将一种类型的异常与另一种类型的异常或将异常包装在其他类型上是没有用的。 99% 的战斗只是有异常细节与什么都没有。只要没有人执行 throw ex(消除堆栈跟踪)，您就会在异常详细信息中获得所需的信息。如果我们在更多异常中包装异常变得聪明，那么我们只会创建更多我们将要忽略的信息。当我们寻找我们真正关心的一件事时，我们将有更多的细节来筛选 - 什么是异常，它是在哪里抛出的？

唯一的异常(exception)(我真的希望我有一个同义词)是如果业务层抛出一个包含面向用户的信息的异常。例如，用户尝试更新某些内容，但他们不能，而您想要包装异常，以便它解释他们需要更正的内容。异常的特定类型可能表明该异常是面向用户的。

但如果异常消息是业务逻辑的结果(“您不能下订单，因为该商品缺货”)那么这真的是一个异常吗？也许那个调用应该返回失败消息而不是抛出异常。我们不应该使用异常来传达消息。