Java异常体系详解与实战应用

有志者，事竟成！如果你在学习文章，那么本文《Java异常体系设计解析与实践》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

绝大多数业务场景下不该自定义Checked Exception，应统一使用RuntimeException子类；仅IO等强契约场景才继承Exception；异常命名需体现具体失败场景，构造器须支持errorCode、message、cause全参数，并实现Serializable。

Java中该不该自定义Checked Exception

绝大多数业务场景下，不该。JDK 7 之后 try-with-resources 和函数式接口普及，Checked Exception 的强制捕获反而破坏API简洁性，尤其在Lambda中会直接编译失败——java.lang.Exception 不是 java.util.function.Function 所允许抛出的异常类型。

真正需要 Checked Exception 的场景极少，典型如：IO资源打开失败必须由调用方决策重试、降级或告警（如自研配置中心客户端首次拉取配置超时），此时才考虑继承 Exception；否则一律用 RuntimeException 子类。

• 所有自定义异常都应继承 RuntimeException，除非有强契约要求调用方必须处理
• 避免为每个错误码新建一个异常类，用单个 BusinessException + errorCode 字段更易维护
• 不要在 service 层 throw SQLException 或 IOException，必须包装成业务语义明确的运行时异常

如何命名和组织业务异常类

异常名必须体现「谁在什么场景下因何失败」，拒绝 MyException、BaseException 这类泛化命名。层级上不建议深继承，2层足够：顶层 BusinessException 表示可预期的业务失败，子类按模块/领域划分，如 OrderNotFoundException、InventoryInsufficientException。

关键点在于构造函数设计：

• 提供 errorCode + message + cause 全参构造器，方便透传原始异常上下文
• 禁止只留 String message 单参构造器——丢失错误码将导致前端无法做差异化提示
• 所有异常类必须实现 Serializable，否则跨服务（如 Dubbo）传递时会反序列化失败

public class OrderNotFoundException extends BusinessException {
    public OrderNotFoundException(String orderId) {
        super(ErrorCode.ORDER_NOT_FOUND, "订单不存在: " + orderId);
    }
    public OrderNotFoundException(String orderId, Throwable cause) {
        super(ErrorCode.ORDER_NOT_FOUND, "订单不存在: " + orderId, cause);
    }
}

throw 异常时最容易被忽略的细节

异常不是日志，抛出即中断流程，但很多人忘了补全关键上下文。最常见问题是：只抛 new BusinessException("库存不足")，却不带具体商品ID、当前库存值、期望扣减量——线上排查时完全无法定位是哪个SKU、哪笔订单触发的问题。

• 永远在异常消息中拼入动态变量，如 "库存不足，商品ID=" + skuId + ", 当前库存=" + actualStock
• 避免在 catch 块里 throw new RuntimeException(e)，这会丢失原始异常类型和堆栈，改用 throw new BusinessException("xxx", e)
• 不要在循环内频繁 throw 同一类异常（如校验集合元素），应聚合错误信息后一次性抛出 ValidationException，含全部失败项

全局异常处理器要不要吞掉异常堆栈

不要。Spring Boot 的 @ControllerAdvice 可统一捕获并返回 JSON，但必须区分环境：开发/测试环境必须返回完整 stackTrace，生产环境则只返回 errorCode 和脱敏后的 message，同时记录带完整堆栈的 ERROR 日志。

否则你永远不知道 NullPointerException 是发生在 DAO 层还是 Controller 层，也看不出是否被多次包装过。

• 日志框架（如 Logback）配置中，确保 %ex 或 %xEx 被启用，否则 logger.error("xxx", e) 不会打印堆栈
• 不要在全局处理器里调用 e.printStackTrace()，它输出到标准错误流，无法被日志系统收集
• 若使用 Sentry / ELK，需在异常对象中显式注入 traceId，否则无法关联请求链路

异常体系真正的难点不在定义多少类，而在于每次 throw 时是否主动思考：这个异常会不会被下游捕获？有没有保留足够信息供排查？堆栈是否真实指向问题源头？

以上就是《Java异常体系详解与实战应用》的详细内容，更多关于的资料请关注golang学习网公众号！