绝大多数业务场景下不该自定义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。
关键点在于构造函数设计：
立即学习“Java免费学习笔记（深入）”；
- 提供
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 时是否主动思考：这个异常会不会被下游捕获？有没有保留足够信息供排查？堆栈是否真实指向问题源头？
