正确保持异常链需确保BusinessException构造函数调用super(message, cause)，直接throw new BusinessException("msg", e)即可；避免仅传message导致断链，调试时通过getCause()或“Caused by”验证链完整性。

直接 throw new BusinessException(e.getMessage(), e) 是正确保持异常链的方式，只要确保构造函数将原异常作为 cause 传入即可。

确认 BusinessException 构造函数支持 cause 参数

关键在于 BusinessException 必须提供接收 Throwable 的构造函数，并显式调用 super(message, cause)：

• ✅ 正确示例：

public class BusinessException extends RuntimeException {
  public BusinessException(String message, Throwable cause) {
    super(message, cause); // 必须调用父类带 cause 的构造器
  }
}

• ❌ 错误写法（丢失 cause）：

public BusinessException(String message, Throwable cause) {
  super(message); // 没传 cause → 断链
}

避免重复包装导致链断裂

不要在捕获后先打印再新建异常，除非明确需要保留原始堆栈；更推荐直接封装：

Java Maven Secondary Analysis

分析ZIP压缩包或GitLab仓库中的Java Maven项目，确定二次开发范围、类数量、模块分布及生产相关指标。

下载

• ✅ 推荐（保持原始堆栈和 cause）：

try {
  // ...
} catch (IOException e) {
  throw new BusinessException("业务操作失败", e); // 直接抛出新异常，e 作 cause
}

• ❌ 风险操作（可能掩盖原始异常）：

} catch (IOException e) {
  log.error("IO异常", e);
  throw new BusinessException("业务操作失败"); // 未传 e → 无异常链
}

日志与调试时验证异常链是否完整

可通过 e.getCause() 或打印完整堆栈确认链是否连通：

立即学习“Java免费学习笔记（深入）”；

• 调用 e.printStackTrace() 时，若输出中包含 “Caused by:” 且后续有原始异常类名和堆栈，则链有效；
• 在 IDE 调试中展开异常对象的 cause 字段，应能逐层看到 IOException → BusinessException → 更上层异常；
• 使用 e.getStackTrace() 查看当前异常堆栈，e.getCause().getStackTrace() 查看被包装异常的堆栈。

统一异常处理建议

为减少手动包装出错，可考虑：

• 定义通用工具方法：BusinessException.wrap(String msg, Throwable e)，内部统一构造；
• 在全局异常处理器（如 Spring 的 @ControllerAdvice）中统一识别 cause 并提取原始错误信息；
• 避免多层重复 wrap，比如 BusinessEx → ServiceEx → ControllerEx，容易造成嵌套过深、定位困难。