异常转译是将底层原始异常（如SQLException）捕获后包装为语义明确的业务异常（如AccountNotFoundException），以屏蔽技术细节、统一错误语义、避免暴露实现，关键需通过cause链保留原始堆栈并补充业务上下文。
在Java中，异常转译（Exception Translation）是指将底层抛出的原始异常（如SQLException、IOException）捕获后，重新包装为更符合当前业务层次或抽象级别的自定义异常（如AccountNotFoundException、PaymentServiceException），从而屏蔽技术细节、统一异常语义，并避免暴露底层实现。
为什么要进行异常转译
直接向上层暴露SQLException或NullPointerException会带来几个问题：
- 违反分层架构原则——数据访问层的异常不应泄露到业务层或表现层
- 调用方需依赖具体技术异常，导致耦合度高、可测试性差
- 异常信息不具业务含义，不利于日志分析和用户提示
- 无法统一处理策略（如重试、降级、告警）
标准做法：使用构造器链式包装
最常用且推荐的方式是通过自定义异常的构造器，将原始异常作为cause传入，保留完整的堆栈追踪：
public class AccountService {
public void transfer(String from, String to, BigDecimal amount)
throws InsufficientBalanceException, AccountLockedException {
try {
accountDao.withdraw(from, amount);
accountDao.deposit(to, amount);
} catch (SQLException e) {
// 转译为业务异常，保留原始异常作为 cause
throw new PaymentServiceException("转账操作失败", e);
} catch (IllegalArgumentException e) {
throw new InvalidAmountException("金额非法: " + e.getMessage(), e);
}
}
}
对应自定义异常示例：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
public class PaymentServiceException extends RuntimeException {
public PaymentServiceException(String message, Throwable cause) {
super(message, cause); // 关键：调用父类含 cause 的构造器
}
}
关键细节与最佳实践
-
始终传递原始异常作为 cause：确保
getCause()可获取根因，便于排查和日志记录（如 SLF4J 的{}占位符自动打印 cause） -
异常类型要有明确语义：比如用
AccountNotFoundException代替泛化的RuntimeException，让调用方能针对性捕获 -
避免“吞掉”异常：不要只写
catch (Exception e) { throw new BusinessException(); }而忽略 cause - 必要时增强错误信息：可在 message 中补充上下文（如“转账失败，源账户[from=1001]余额不足”），但不要丢弃原始异常
-
区分 checked / unchecked：业务逻辑异常通常继承
RuntimeException（unchecked），若需强制调用方处理，可继承Exception（checked），但需谨慎权衡
进阶技巧：统一异常处理器与模板方法
对于重复的转译逻辑（如 DAO 层统一转译 JDBC 异常），可用模板方法或 AOP 简化：
- DAO 基类中封装
translateSQLException(SQLException)方法，按 SQLState 或 ErrorCode 映射为不同业务异常 - Spring 中配合
@ControllerAdvice和@ExceptionHandler，在 Web 层统一将ServiceException转为 HTTP 状态码和 JSON 错误响应 - 使用 Lombok 的
@SneakyThrows要小心——它绕过编译检查，但未真正解决异常转译需求
异常转译不是简单地“换个名字”，而是构建清晰异常边界、提升系统可维护性的基础设计习惯。只要保持 cause 链完整、语义准确、层次分明，就能让错误处理既健壮又易懂。
