Java封装底层异常的核心动机是解耦与语义收敛：隔离实现细节、统一错误码与日志、防止敏感信息泄露、提升方法签名可读性；应设计轻量可扩展的AppException基类，包装时用addSuppressed替代cause并提取关键信息，AOP仅作兜底而非主责。
Java 中封装底层异常不是为了“美化”错误，而是为了隔离实现细节、控制异常传播边界、避免上层代码被无关技术栈污染。直接 throw SQLException 或 IOException 到 service 层，等于把数据访问层的选型和故障细节暴露给了业务逻辑。
为什么要用自定义异常包装底层异常
核心动机是「解耦」与「语义收敛」：
- 避免上层模块依赖具体技术异常（如
org.springframework.dao.DuplicateKeyException），否则换 ORM 框架就得改所有 catch 块 - 统一错误码、日志上下文、重试策略等横切关注点，不散落在各处 try-catch 中
- 防止敏感信息泄露（比如数据库连接失败时，
java.net.ConnectException里可能含 host/port） - 让业务方法签名更干净——
public Order createOrder(...) throws BusinessException比throws SQLException, TimeoutException, JsonProcessingException更可读、更稳定
如何设计可扩展的异常基类
不要一上来就写一堆 ValidationException、NetworkException……先建一个轻量但有扩展能力的根异常：
public abstract class AppException extends RuntimeException {
private final int code;
private final String requestId;
protected AppException(int code, String message, String requestId, Throwable cause) {
super(message, cause);
this.code = code;
this.requestId = requestId;
}
public int getCode() { return code; }
public String getRequestId() { return requestId; }
}
关键点：
立即学习“Java免费学习笔记（深入）”；
-
code必须是整数——方便前端 switch、监控系统聚合、日志采样过滤 - 构造函数保留
cause参数，确保堆栈不丢失；但子类应主动 suppress 底层异常的 stack trace（见下节） - 不加
Serializable——除非你真在跨 JVM 传递异常（RPC 场景极少需要） - 子类只负责语义分类，不新增字段；额外元数据（如失败字段名、限流阈值）走
Map<String, Object>或专用 context 对象传入，而非塞进异常类
包装时怎么处理原始异常的堆栈
直接 new BusinessException("xxx", e) 会把整个底层堆栈打出来，日志里满屏 Caused by: java.sql.SQLTimeoutException，既干扰排查重点，又可能泄漏内部结构。正确做法：
- 调用
Throwable.addSuppressed()替代直接设 cause（JDK7+）——保留原始异常但不自动打印 - 或在日志中显式记录：
log.warn("DB timeout for order {}", orderId, e);，然后抛出干净的AppException - 若需透传部分信息（如 SQLSTATE），提取后作为字段注入，而不是把整个
SQLException当 cause
示例：
try {
jdbcTemplate.update(sql, params);
} catch (DataAccessException e) {
BusinessException ex = new BusinessException(5001, "创建订单失败", requestId);
ex.addSuppressed(e); // 不触发默认链式打印
throw ex;
}
Spring AOP 统一封装的边界在哪
AOP（如 @ExceptionHandler）适合做「兜底」，但不能替代主动封装：
- 它只能捕获已抛出的异常，对异步线程、CompletableFuture、lambda 内部异常无效
- 无法控制异常构造时机——比如你希望在 DAO 层就带上当前租户 ID，AOP 拦截时这个上下文可能已丢失
- 容易掩盖本该由业务层决策的异常（例如幂等校验失败该重试还是拒绝？AOP 一刀切返回 409 就错了）
真正合理的分层是：DAO → 自定义异常（带 code + 关键参数）→ Service 根据场景决定是否重试/转换/合并 → Controller 返回 HTTP 状态码。AOP 只补漏，不主责。
最难把握的是“封装粒度”：包一层空壳叫 DaoException 没意义；包十层嵌套还带泛型参数的异常体系反而增加维护成本。从一个 AppException 开始，按真实 error code 分组演进，比预设一整套继承树更可靠。
