在Java中如何封装底层异常_Java异常抽象设计解析_技术教程

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; }
}

关键点：

code 必须是整数——方便前端 switch、监控系统聚合、日志采样过滤
构造函数保留 cause 参数，确保堆栈不丢失；但子类应主动 suppress 底层异常的 stack trace（见下节）
不加 Serializable ——除非你真在跨 JVM 传递异常（RPC 场景极少需要）
子类只负责语义分类，不新增字段；额外元数据（如失败字段名、限流阈值）走 Map 或专用 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;
}