catch块按声明顺序从上到下匹配，首个兼容类型即执行；子类异常须置于父类前，否则编译报错；finally总执行且可覆盖返回值或压制原异常；多异常捕获要求类型无继承关系。
catch块的匹配顺序是从上到下严格执行的
Java虚拟机在抛出异常时，会按try语句后catch块的**声明顺序**逐个比对异常类型，一旦找到第一个能匹配（即异常实例是该类型或其子类）的catch，就立即进入该块执行，后续catch全部跳过。这和if-else链逻辑一致，不是“找最精确匹配”。
常见错误现象：Catch顺序写反导致子类异常被父类catch提前捕获，编译器会报错“unreachable catch block”：
try {
throw new IOException();
} catch (Exception e) { // ← 先写这个，下面的IOException永远进不来
} catch (IOException e) { // ← 编译失败：unreachable catch block
}
- 必须把更具体的异常（如
NullPointerException、IOException）放在更通用的（如Exception、Throwable）之前 - 接口类型（如
SQLException）和其实现类（如SQLTimeoutException）也需注意继承关系 - 如果多个
catch参数类型无继承关系（如IOException和IllegalArgumentException），顺序不影响正确性，但建议按业务频次或严重程度组织，便于阅读
finally块总是在控制流离开try-catch时执行（除System.exit等极端情况）
finally不是“只有异常发生才执行”，而是只要进入了try块，无论正常结束、return、break、还是抛出异常，finally都会被执行——这是JVM字节码层面保证的。
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
-
try里有return，finally里也有return→ 后者会覆盖前者返回值（基本类型和不可变对象表现明显） -
finally里抛出新异常 → 原异常会被丢弃，调用栈只显示finally里的异常（除非显式保存并重抛） - 在
finally中修改对象字段是安全的，但不要在里面做可能失败的操作（如关闭已关闭的流），否则可能掩盖原始异常
多异常捕获（|语法）要求所有异常互不继承
Java 7 引入的多异常捕获写法：catch (IOException | SQLException e)，本质是编译器生成多个独立catch块，但共享同一段处理逻辑。它只允许并列的、彼此没有继承关系的异常类型。
以下写法非法：
catch (IOException | Exception e) // 编译错误：Exception是IOException的父类
- 类型列表中任意两者不能是父子类关系，否则编译报错“alternative exception type is already caught”
- 捕获变量
e的静态类型是这些类型的**最小公共父类**（通常是Exception），所以只能调用该父类声明的方法 - 适合处理多种异常但修复逻辑完全一致的场景（如统一打日志+返回默认值），不适用于需要差异化处理的情况
try-with-resources的异常压制机制常被忽略
当try块抛出异常，且try中声明的资源（实现AutoCloseable）在close()时也抛异常，JVM会将close()异常作为“suppressed exception”附加到主异常上，而不是覆盖它。
这意味着：
- 主异常的
printStackTrace()默认不显示被压制的异常，需调用getSuppressed()手动获取 - 如果
try块没异常，仅close()失败，则该异常正常抛出 - 多个资源依次关闭，前面资源
close()失败不会阻止后面资源关闭，但所有失败都会被压制并记录
实际调试时，光看主异常堆栈可能漏掉关键线索，尤其在文件读写、数据库连接等场景下，close()失败往往暴露资源泄漏或权限问题。
