直接throw e不会丢失原始堆栈，仅在顶部新增当前方法帧；而throw new XxxException(e)适用于需转换异常类型或增强语义的场景。
catch里直接throw e会丢失原始堆栈吗
会。如果在 catch 块中写 throw e;（其中 e 是捕获的异常对象），原始异常的堆栈信息不会丢失，但调用链上会多出一层当前方法的帧——这本身不是问题，但容易让人误以为异常是从这里“新抛出”的。
真正丢失堆栈的是用 new RuntimeException(e.getMessage()) 这类方式包装再抛，它会切断与原始异常的关联。
- ✅ 正确：直接
throw e;—— 保留原始StackTraceElement，只是顶部多了一行当前方法 - ❌ 错误：构造新异常且不传入
e作 cause，如throw new RuntimeException("处理失败"); - ⚠️ 注意：
throw new RuntimeException(e);是安全的，因为构造函数接受Throwable作为 cause，能保留根因和完整堆栈
用throw e还是throw new XxxException(e)更合适
取决于你是否需要改变异常类型或补充上下文。Java 异常传递的核心原则是：**不掩盖原始错误，但可增强语义**。
- 保持原类型 + 补充日志？→ 直接
throw e;，并在catch中先log.error("xxx", e); - 要转成业务异常（如把
IOException转为UserServiceException）？→ 用带 cause 的构造器：throw new UserServiceException("用户保存失败", e); - 需修改消息但保留根因？→ 同样走带 cause 构造器，不要只改
getMessage()后重抛
多数 Spring 项目倾向后者，因为 Controller 层通常只处理特定业务异常，底层 IO/DB 异常应被封装。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
try-catch-finally里重新抛异常的执行顺序陷阱
很多人以为 finally 里的代码一定在 throw 之后执行——其实不然。如果 finally 里也有 throw 或返回值，它会覆盖 catch 中的抛出。
try {
throw new NullPointerException("A");
} catch (NullPointerException e) {
System.out.println("catch");
throw new IllegalArgumentException("B");
} finally {
System.out.println("finally");
throw new RuntimeException("C"); // ← 这个会实际抛出，B 被吞掉
}
- 上面代码最终抛出的是
RuntimeException("C")，IllegalArgumentException("B")彻底丢失 - 若
finally中只是普通语句（如关流、打日志），不影响catch的抛出 - Java 7+ 推荐用 try-with-resources 替代手动
finally关流，避免此类干扰
re-throw时要不要加throws声明
要看你抛出的是检查异常（checked exception）还是非检查异常（unchecked）。Java 编译器强制要求：
- 如果
catch中throw的是检查异常（如IOException），且当前方法签名没声明throws IOException，编译失败 - 如果抛出的是运行时异常（
RuntimeException及其子类），无需声明throws - 即使你把检查异常包装成运行时异常（如
throw new RuntimeException(e)），也无需声明 —— 但要注意调用方可能因此收不到编译期提醒
这也是为什么很多框架选择将底层检查异常统一转为自定义运行时异常：既免去层层 throws，又不失错误语义。
finally 拦截、以及调用链上谁该负责处理它——这些决策比语法更重要。 
