java中应直接用throw e;原样重抛捕获的异常，以保持堆栈和cause链完整；切忌在finally中throw，避免覆盖原始异常；检查型异常重抛须声明throws或转为runtimeexception。
Java中用throw重新抛出捕获的异常
直接用throw语句把刚捕获的异常再抛出去，是最常见也最安全的重新抛出方式。它保持原始异常的类型、堆栈信息和cause链完整，不会丢失调试线索。
常见错误是误写成throws（那是声明，不是动作），或在catch块里新建一个异常再抛（比如throw new RuntimeException(e)），这会截断原始堆栈。
- 必须用
throw e;，其中e是catch参数 - 不要对
e做任何包装，除非你明确需要改变异常语义 - 如果方法签名没声明该异常，且它是检查型异常（checked exception），编译会报错——此时要么加
throws声明，要么用RuntimeException包装（但慎用）
public void process() throws IOException {
try {
readFile();
} catch (IOException e) {
// 正确：原样重抛
throw e;
}
}
用throw new RuntimeException(e)包装后再抛
当被调用的方法声明了检查型异常，而你所在的层级不想暴露这个细节（比如在Spring Controller里统一处理），常用这种包装方式。但它会把原始异常变成cause，顶层堆栈从RuntimeException开始，可能掩盖真实出错位置。
关键点在于：JVM 仍保留原始异常作为cause，所以日志或调试时用e.getCause()还能拿到；但IDE 的异常断点、某些监控工具可能只显示外层。
立即学习“Java免费学习笔记（深入）”；
- 适合屏蔽底层技术细节（如把
SQLException转为业务无关的ServiceException） - 避免在
catch里写throw new RuntimeException("xxx", e)却不保留e作cause——那等于丢掉根因 - Spring 的
@ExceptionHandler通常更推荐直接返回响应，而非层层包装重抛
try {
jdbcTemplate.queryForObject(sql, String.class);
} catch (EmptyResultDataAccessException e) {
// 包装但保留cause，可追溯
throw new ServiceException("用户不存在", e);
}
在finally块中调用throw的风险
绝对不要在finally里写throw。如果try块已抛出异常，finally里的throw会覆盖它，导致原始异常永远丢失——这是极难排查的静默故障。
典型场景是资源关闭失败时想报错，结果把前面的NPE或SQL异常给吞了。
-
finally只做清理（如close()），出错也应log.error，而不是throw - JDK 7+ 推荐用
try-with-resources，自动处理关闭逻辑，规避手写finally的陷阱 - 若真要报告关闭异常，可用
addSuppressed()追加到主异常上（Java 7+）
try (FileInputStream fis = new FileInputStream("a.txt")) {
// ...
} catch (IOException e) {
// 主异常
throw e;
// 即使fis.close()内部失败，也不会覆盖e
}
异常传播中throws声明与实际抛出不一致的编译错误
Java 编译器会校验：方法体中所有可能抛出的**检查型异常**，都必须在方法签名的throws子句中显式列出。如果你在catch里重抛了一个未声明的检查型异常，编译直接失败。
这不是运行时问题，而是编译期契约。非检查型异常（RuntimeException及其子类）不受此限。
- 例如
catch (ParseException e) { throw e; }，而方法没写throws ParseException→ 编译报错 - 解决方式只有两个：补上
throws，或把ParseException转为RuntimeException子类（如IllegalArgumentException） - 别试图用
throws Exception糊弄——这会让调用方失去异常语义，违背设计初衷
真正麻烦的是跨模块协作时，一方悄悄改了throws列表却没同步文档或接口定义，下游编译就炸。这类问题往往卡在CI阶段才暴露。
