正确使用异常包装需在抛出新异常时保留原始异常作为cause，例如将SQLException包装为ServiceException并传入原异常，确保调用方可通过getCause()获取底层异常信息，打印堆栈时会显示完整链路，自定义异常应提供含Throwable参数的构造函数以支持异常链，避免丢失原始异常或过度包装导致调试困难。
在Java开发中，经常需要将底层异常转换为更高层次的异常，以便调用方更容易理解错误上下文。这种做法称为异常包装。正确使用异常包装不仅能隐藏实现细节，还能保留原始异常信息，便于排查问题。
使用构造函数传递底层异常
大多数自定义异常或标准异常类都提供接受 Throwable 类型参数的构造函数，用于保存原始异常引用。这是实现异常包装的基础。
例如，你在访问数据库时遇到 SQLException，但希望向上抛出一个更通用的 ServiceException：
try {
dao.save(data);
} catch (SQLException e) {
throw new ServiceException("数据保存失败", e);
}
这里将 SQLException 包装进 ServiceException，原始异常作为“原因（cause）”被保留。调用方可以通过 getCause() 获取底层异常。
立即学习“Java免费学习笔记（深入）”；
确保异常链完整（Exception Chaining）
Java 的异常机制天然支持异常链。只要在抛出新异常时传入原异常，JVM 就会自动维护这个因果关系。
关键点：
- 使用支持 cause 参数的构造函数，如 Exception(String message, Throwable cause)
- 避免只传消息而丢失底层异常，否则调试困难
- 打印堆栈时，整个异常链都会输出，便于追踪根源
} catch (IOException e) {
throw new BusinessException("文件处理出错", e);
}
当调用 printStackTrace() 时，不仅会显示 BusinessException 的堆栈，还会递归打印 IOException 的堆栈信息。
自定义异常中的包装处理
如果你定义自己的异常类，建议提供接收 Throwable 的构造方法，以支持异常包装。
public class AppException extends Exception {
public AppException(String message) {
super(message);
}
public AppException(String message, Throwable cause) {
super(message, cause);
}
}
这样在业务逻辑中就能统一处理异常转换，同时保持堆栈完整性。
避免过度包装或信息丢失
虽然包装异常很有用，但也需要注意：
- 不要频繁包装同一异常，导致堆栈过深
- 不要忽略原始异常，仅记录日志却不抛出，这会中断异常链
- 在日志中可同时记录当前异常和 getCause()，帮助定位问题
如果只是记录日志而不改变异常类型，可以直接抛出原异常或使用 throws 声明。
基本上就这些。合理使用异常包装能让系统分层更清晰，错误信息更友好，同时不牺牲调试能力。关键是始终把底层异常作为 cause 传入新异常，保证异常链不断开。
