多数情况下不该新建异常对象，而应复用原异常并用initCause()或带cause的构造函数传递，否则会丢失原始堆栈，导致调试时无法定位最初出错位置。
Java里用 throw 重新抛出异常，到底该不该新建对象？
直接说结论：**多数情况下不该新建异常对象，而应复用原异常并用 initCause() 或构造函数链式传递**。否则会丢失原始堆栈，调试时根本找不到最初出问题的那行代码。
常见错误现象是日志里只看到最外层的 RuntimeException，但 Caused by: 下面空空如也——这就是没做异常链导致的。
- 如果原异常是受检异常（比如
IOException），而当前方法声明不抛它，又不想捕获后吞掉，就用throw new RuntimeException(originalException)，它会自动把原异常设为 cause - 如果想保留原异常类型（比如仍抛
IOException），且 JDK ≥ 7，优先用带 cause 的构造函数：throw new IOException("读取失败", originalException) - JDK 6 及更早版本不支持所有异常都有 cause 构造函数，此时得手动调
initCause()，但注意：只能调一次，且不能对已设过 cause 的异常再调
为什么 catch { throw e; } 看似省事却埋了雷？
这种写法不会重置堆栈，看起来“没动原异常”，但实际会把异常的 stackTrace 更新为当前 throw 所在位置——原始抛出处的行号、方法名全被覆盖了。
典型使用场景是 AOP 切面或通用拦截器里做统一日志记录后放行异常，结果运维查问题时发现堆栈指向切面代码，而非业务逻辑本身。
立即学习“Java免费学习笔记（深入）”；
- 正确做法是用
throw e;前先调e.fillInStackTrace()强制恢复原始堆栈（但极少需要，通常说明设计有问题） - 更合理的路径是：记录日志 → 不 throw 原异常 → 改用包装后抛出，例如
throw new ServiceException("订单处理异常", e) - 某些框架（如 Spring）的
@ExceptionHandler默认保留原始堆栈，但自定义全局异常处理器时若手动throw e;，就得小心这个陷阱
Exception 包装时，选 RuntimeException 还是自定义异常类？
取决于调用方是否需要强制处理。包装本身不是目的，关键是让上层能区分“可预期的业务失败”和“不可控的系统故障”。
性能影响几乎可忽略，但兼容性要注意：自定义异常类必须实现 Serializable（如果走 RMI 或序列化传输），且无参构造函数不能丢。
- 对外 API 层建议用受检异常包装（如
ApiException），迫使调用方思考错误分支 - 内部 service 层常用运行时异常包装（如
ServiceException），避免满屏throws声明污染接口 - 不要用
Exception或Throwable直接包装——它们太宽泛，下游无法针对性 catch - 所有包装异常的构造函数都应提供
String message, Throwable cause重载，这是链式传递的基础
异常链里 getCause() 拿不到最底层原因？
因为有些中间异常（尤其是老框架或 JDBC 驱动）压根没设置 cause，或者用了非标准方式“吞掉”了原始异常。这时候靠一层 getCause() 肯定不够。
真实调试场景中，你经常得顺着链往下挖三层以上才能定位到 SQLException: Connection refused 这种根因。
- 别手写循环调
getCause()，用 Guava 的Throwables.getRootCause(e)或 Apache Commons Lang 的ExceptionUtils.getRootCause(e) - 自己实现时注意 null 判断，且要防循环引用（虽然罕见，但某些代理异常会把自己设为 cause）
- 日志框架如 Logback 的
%ex{full}默认展开整个异常链，但 Log4j 1.x 默认只打一层——配置里得显式写%xEx或升级到 Log4j 2
异常链不是加了 cause 就万事大吉，从捕获、包装、传递到最终日志落地，每个环节都可能断掉。最容易被忽略的是：包装时忘了传 cause，或者用了不支持 cause 的旧版异常类。
