Java异常默认自动向上抛出：未捕获的checked异常需声明throws，unchecked异常可直接冒泡；传播由JVM自动完成，无需手动throw；吞掉异常或丢失堆栈是常见错误。
Java中异常如何自动向上传播到调用栈顶层
Java的异常默认就是“向上抛出”的：只要方法里没用 try-catch 捕获，且声明了该异常（或它是 RuntimeException 及其子类），它就会自动沿调用链往上传，直到被某层捕获，或到达 main 方法后终止线程并打印堆栈。
关键点在于：这种传播不依赖手动“重新 throw”，也不需要你在每一层都写 throw e —— 它是 JVM 的默认行为。
-
checked exception（如IOException）必须显式处理：要么catch，要么在方法签名加throws声明，否则编译失败 -
unchecked exception（如NullPointerException、IllegalArgumentException）可不声明、不捕获，照样向上冒泡 - 即使中间某层用了
catch但没做任何处理，又直接throw e，堆栈信息仍保持原始位置（除非用throw new XxxException(e)包装，会丢失原始栈帧）
什么时候必须用 throws 声明异常
只对 checked exception 强制要求。比如你调用 FileInputStream 构造函数，它声明抛出 FileNotFoundException，那你的方法若不捕获，就必须在签名中写 throws FileNotFoundException 或其父类 IOException。
- 可以声明多个异常，用逗号分隔：
throws IOException, SQLException - 子类重写父类方法时，
throws列表不能新增checked exception（可缩小，或改用更具体的子类，但不能加原来没有的类型） - 如果方法里调用了多个可能抛出不同
checked exception的 API，而你又不想在本层处理，就全列在throws里 —— 否则编译报错：unreported exception XXX; must be caught or declared to be thrown
多层调用中不要“吞掉”异常又静默返回
这是最常见也最危险的误用：在某层 catch 了异常，却只打了一行日志或什么也不做，然后继续执行后续逻辑，甚至返回一个“成功”结果。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 调用方完全感知不到失败，可能基于错误状态继续运算，导致数据错乱或空指针后续爆发
- 典型反模式：
catch (Exception e) { logger.error("ignored", e); return null; } - 正确做法取决于场景：若该异常代表业务不可恢复的失败（如数据库连不上），应让异常继续上抛；若能降级处理（如缓存失效时回源失败，可返回默认值），也要明确记录 + 标记降级，而非掩盖异常信号
包装异常时怎么保留原始堆栈
当需要把底层异常转为更高层语义的异常（比如把 SQLException 转成 UserNotFoundException），要用构造函数传入 cause：
throw new UserNotFoundException("user id " + id + " not found", e);
这样打印堆栈时能看到完整链条，包括原始 SQLException 的位置。如果写成 new UserNotFoundException(e.getMessage())，原始堆栈就丢了。
- 所有标准异常类（
Exception、RuntimeException等）都支持带Throwable参数的构造函数 - 自定义异常记得提供这个构造函数，并在内部调用
super(cause) - 不要用
e.printStackTrace()替代异常传播 —— 它只是输出到 stderr，不中断流程，也不传递上下文
真正容易被忽略的是：异常传播不是靠“代码写了 throw”才发生，而是靠“没拦住”。很多问题其实出在某一层看似“处理了”，实则悄悄吃掉了关键错误信号。
