异常设计——每一层的自定义异常答案

【问题标题】：Exception design - Custom exception at every layer异常设计——每一层的自定义异常
【发布时间】：2023-03-05 14:49:01
【问题描述】：

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

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

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

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

我希望所有错误都传播到 Web API，我们使用错误过滤器来拦截、记录错误并更改 Context.Response 以向最终用户提供友好的消息，这样做的好处是：

错误源保持不变
我们处理需要的异常
简单直接的错误处理机制

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

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

对我来说，这种设计的问题是：

更改异常的来源，这不是一个好的做法
捕获异常而不进行任何处理
在任何地方添加 try catch 会产生大量额外代码，据我了解，这会影响性能

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

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

【问题讨论】：

据我了解，这是一个非常通用的设计问题，对 c# 和 Java 都有效，即使我的代码在 c# 中也是如此

标签： java c# exception exception-handling

【解决方案1】：

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

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

有许多不同的方式来实现拦截。这可能取决于您的应用程序中已包含哪些工具。我使用Windsor 进行依赖注入，因此使用它们的拦截器很方便。如果我不使用 Windsor，我会查看 PostSharp。

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

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

与拦截无关：

在实践中，我发现大多数时候将一种类型的异常与另一种类型的异常或将异常包装在其他类型上是没有用的。 99% 的战斗只是有异常细节而不是什么都没有。只要没有人这样做throw ex（消除堆栈跟踪），那么您将在异常详细信息中获得所需的内容。如果我们巧妙地将异常包装在更多异常中，那么我们只会创建更多我们将忽略的信息。当我们寻找我们真正关心的一件事时，我们将有更多的细节需要筛选——异常是什么以及它是在哪里抛出的？

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

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

【讨论】：

感谢您提供的详细信息，在我的情况下很有意义

【解决方案2】：

拥有最初抛出错误的堆栈跟踪是很有价值的。如果异常被捕获并重新抛出，则将异常添加到内部异常中很重要，这样信息就不会丢失。根据我的经验，捕获和重新抛出异常的论点来自不熟悉使用堆栈跟踪进行调试的开发人员。

如果您要捕获并重新抛出异常，它确实会创建额外的代码来遍历内部异常。必须记录或传输这些数据，这增加了存储要求或网络开销。在调试与引发的异常相关的问题时，还有更多数据需要筛选，这可能会增加开发人员所需的时间。

另一方面，如果开发人员可以预测异常并在编写代码时使用这种洞察力，那么提供额外的顶级信息会很有帮助，因此在这种情况下捕获并重新抛出异常可能是有效的。特别是在其他（可能经验不足的）开发人员将使用相同代码的情况下。如果异常是可预测的，但在许多情况下，最好处理错误并做出相应的行为，而不是抛出异常。

在应用程序/dll 边界捕获异常可能很有价值。当这些组件被其他开发人员使用或被最终用户使用时，这样做可以减少使用这些模块进行开发的脆弱性。

【讨论】：

【解决方案3】：

用异常链重新抛出异常并在过滤器中解析这个链怎么样（只选择链中的第一个异常（原因）或解析所有层的所有上下文）？

class App {
    public static void main(String[] args) {
        View view = new View();
        try {
            System.out.println(view.doRender());
        } catch (ViewException e) {
            System.out.println("ERROR: " + unrollChain(e));
        }
    }

    static String unrollChain(Exception e) {
        Throwable current = e;
        while (current.getCause() != null) {
            current = current.getCause();
        }
        return current.getMessage();
    }
}

class View {
    private Business business = new Business();

    String doRender() throws ViewException {
        try {
            return "<html>" + business.doBusiness() + "</html>";
        } catch (BusinessException e) {
            if (System.nanoTime() % 2 == 0)
                throw new ViewException("Some context if have one", e);
            else
                throw new ViewException(e); // no local context, pure rethrow
        }
    }
}

class Business {
    private Dao dao = new Dao();

    int doBusiness() throws BusinessException {
        try {
            return dao.select() + 42;
        } catch (DaoException e) {
            if (System.nanoTime() % 2 == 0)
                throw new BusinessException("Some context if have one", e);
            else
                throw new BusinessException(e); // no local context, pure rethrow
        }
    }
}

class Dao {
    int select() throws DaoException {
        if (System.nanoTime() % 2 == 0)
            return 42;
        else
            throw new DaoException();
    }
}

class DaoException extends Exception {
}

class BusinessException extends Exception {
    public BusinessException(String message, Throwable cause) {
        super(message, cause);
    }

    public BusinessException(Throwable cause) {
        super(cause);
    }
}

class ViewException extends Exception {
    public ViewException(String message, Throwable cause) {
        super(message, cause);
    }    
    public ViewException(Throwable cause) {
        super(cause);
    }
}

【讨论】：

据我了解，这种设计只会使事情变得复杂，正如@Scott Hannen 所提到的，这只会增加信息量，我们宁愿忽略这些信息，同时丢失原始异常源