Java异常未捕获时自动沿调用栈向上抛出：checked异常需throws声明，unchecked异常可直接抛；应保留原始堆栈信息，避免丢失cause；捕获与否取决于当前层能否真正处理异常而非仅记录日志。
Java中异常不捕获时会自动向上抛出
Java的异常传播机制决定了：只要方法里没用 try-catch 捕获，且方法声明了可能抛出该异常（或它是 RuntimeException），异常就会沿调用栈逐层向上传递，直到被处理或程序终止。
这意味着你不需要手动“传递”异常——它天然具备穿透性。常见误解是试图用参数或返回值“转发”异常，这反而破坏了JVM的异常处理逻辑。
-
checked exception（如IOException）必须在方法签名中用throws声明，否则编译失败 -
unchecked exception（如NullPointerException、IllegalArgumentException）可不声明，直接抛出 - 即使中间方法只做日志或资源清理，也应使用
finally或try-with-resources，而不是吞掉异常
多层调用中如何保留原始堆栈信息
最常踩的坑是用 new RuntimeException(e.getMessage()) 包装异常——这会丢失原始 StackTrace，导致无法定位真正出错位置。
正确做法是将原始异常作为 cause 传入构造函数，让 JVM 自动维护嵌套关系：
立即学习“Java免费学习笔记（深入）”；
public void service() throws IOException {
try {
dao.query();
} catch (SQLException e) {
// ✅ 正确：保留 cause 和完整 stack trace
throw new IOException("Query failed", e);
}
}
- 所有标准异常构造函数都支持
Throwable cause参数 - 自定义异常类务必提供带
cause的构造函数，并调用super(message, cause) - 避免用
e.toString()或e.getMessage()拼接新异常，它们不含堆栈
何时该捕获、何时该声明 throws
关键看当前层是否能“处理”异常语义，而不是“能不能执行完”。比如数据库连接失败，Service 层通常无法修复网络问题，就不该在这里 catch 后静默返回 null；而应该让 Controller 或全局异常处理器统一响应 HTTP 500。
- 能恢复（如重试、降级、返回默认值）→
try-catch - 只能记录日志 + 清理资源 →
try-catch-finally或try-with-resources，然后throw原异常或包装后抛出 - 完全无业务含义（如
InterruptedException）→ 立即响应中断，通常抛出RuntimeException或重新设置线程中断状态 - 跨模块边界（如 DAO → Service → Controller）→ 优先用
throws显式声明，避免隐藏失败契约
Spring等框架对异常传播的影响
Spring 的 @Transactional 默认只对 RuntimeException 回滚，对 checked exception 不回滚——这不是异常传播失效，而是框架主动忽略。如果你在 service 方法里抛出 IOException，事务依然提交，除非显式配置 rollbackFor = IOException.class。
另外，Spring MVC 的 @ExceptionHandler 是在 DispatcherServlet 拦截后才生效，意味着异常必须一路透传到 controller 层之上，中间不能被吞掉。
- 不要在 service 层用
try-catch捕获后返回错误码，这会让事务和全局异常处理失效 - 若需转换异常类型（如把 DAO 的
SQLException转为领域异常UserNotFoundException），仍需保留 cause - 异步方法（
@Async）中抛出的异常不会传播到调用方线程，必须显式处理或通过Future.get()获取
