应使用带 Throwable cause 参数的构造方法，如 new BusinessException("业务异常", e)，才能保留原始异常的堆栈跟踪和根本原因；仅用 getMessage() 会丢失类名、行号、调用链等关键诊断信息。
因为 new BusinessException(e.getMessage()) 创建的是一个全新异常对象，只复制了原异常的错误消息，没保留原始异常的堆栈跟踪（stack trace），更没设置 cause（根本原因）。
丢失堆栈的根本原因
Java 中每个异常对象在构造时会自动捕获当前线程的执行栈并保存为 stack trace。当你用 new BusinessException(String) 构造时，JVM 会在这一行重新生成新的堆栈，覆盖掉原来的；而原异常 e 的堆栈并未被关联或传递过去。
正确保留原异常信息的方式
应该使用支持 cause 参数的构造方法，把原异常作为“根本原因”传入：
- 确保
BusinessException提供了带Throwable参数的构造函数，例如：public BusinessException(String message, Throwable cause) {<br> super(message, cause);<br>} - 抛出时写成：
throw new BusinessException("业务异常", e); - 这样原异常
e会被设为 cause，调用printStackTrace()或日志框架输出时，会同时显示 BusinessException 的堆栈 + 原异常的完整堆栈（含 “Caused by” 链）。
为什么 getMessage() 不够用
e.getMessage() 只是字符串，不包含类名、行号、调用链等关键诊断信息。很多问题靠消息无法定位，比如空指针发生在哪一行、被谁调用、上下文是什么——这些全靠堆栈。
立即学习“Java免费学习笔记（深入）”；
常见误区与替代方案
- 不要用
throw new BusinessException(e.toString())：仍是字符串，堆栈照样丢。 - 不要手动拼接堆栈字符串：易出错、不可靠、破坏标准异常处理机制。
- 如果无法修改 BusinessException 类，可用
initCause(e)（但必须在构造后立即调用，且仅一次）；不过推荐优先升级构造函数支持 cause。
不复杂但容易忽略：只要传 cause，堆栈就跟着走。
