异常包装是将低级异常封装为业务异常的技术，通过保留异常链提升代码抽象层次与可维护性。
在Java开发中，异常处理是保障程序健壮性的重要环节。当调用底层方法时，常常会抛出低级异常（如SQLException、IOException等），这些异常对上层业务逻辑来说往往过于具体或难以理解。为了提升代码的可维护性和调用方的使用体验，通常采用异常包装的方式将低级异常转换为更高级别的业务异常。
什么是异常包装
异常包装是指捕获一个异常后，将其作为“原因”（cause）封装到一个新的、更合适的异常中并重新抛出。Java中的异常链机制支持这一特性，通过构造函数传入原始异常，保留完整的错误上下文。
例如：
try {
// 可能抛出IOException的操作
Files.readAllLines(Paths.get("config.txt"));
} catch (IOException e) {
throw new ConfigLoadException("加载配置文件失败", e);
}
这里ConfigLoadException是自定义的业务异常，它把底层的IOException包装起来，使调用方无需关心具体I/O细节，同时仍可通过getCause()追溯根本原因。
立即学习“Java免费学习笔记（深入）”；
为什么要进行异常包装
直接暴露低级异常会带来以下几个问题：
-
泄露实现细节：调用方看到
SQLException会误以为必须处理数据库相关逻辑，破坏了抽象层次。 - 不利于维护：如果将来更换数据存储方式（如从数据库改为文件），异常类型变化会导致上层代码大量修改。
- 语义不清晰：低级异常无法准确表达业务含义，比如“用户注册失败”比“Connection refused”更容易理解。
通过包装，可以统一异常体系，隐藏技术细节，提高模块间的解耦程度。
如何正确进行异常包装
在实践中，应遵循以下几点原则来有效包装异常：
-
选择合适的异常类型：根据业务场景定义有意义的异常类，如
UserNotFoundException、PaymentFailedException，避免滥用RuntimeException。 -
保留原始异常信息：务必在新异常构造函数中传入原异常，确保堆栈轨迹完整。Java所有标准异常都支持带
Throwable cause的构造函数。 - 提供清晰的错误消息：新异常的消息应描述当前操作的失败原因，而不是重复底层异常内容。例如：“读取用户配置失败”而非“File not found”。
- 避免过度包装：不要层层包装相同类型的异常，防止调用栈过深。若已在服务层处理并包装，则DAO层不应再额外包装一次。
实际应用场景示例
假设有一个用户服务需要从数据库加载用户信息：
public User findUserById(Long id) {
try {
return userRepository.findById(id);
} catch (SQLException e) {
throw new UserServiceException("查询用户失败，ID=" + id, e);
}
}
在这个例子中，即使底层使用JDBC操作数据库，上层调用者只需处理UserServiceException，无需导入SQL相关的类。未来若改为NoSQL存储，只需更改实现而不影响接口契约。
基本上就这些。合理使用异常包装能让系统更具弹性与可读性，关键是保持异常语义清晰，并始终保留根因以便排查问题。
