Java 7+ 多异常捕获要求 | 分隔的异常类型必须互不继承，否则编译报错；e 的静态类型为最小公共父类，无法调用子类特有方法；老版本需按继承顺序写多个 catch；多异常下需用 instanceof 区分处理。
Java 7+ 用 | 捕获多个异常必须是互不相关的类型
Java 7 引入了多异常捕获语法，允许在一个 catch 块中处理多种异常，但前提是这些异常类之间不能有继承关系。否则编译直接报错：Alternatives in a multi-catch statement cannot be related by subclassing。
常见错误是把 IOException 和它的子类 FileNotFoundException 同时写在同一个 catch (IOException | FileNotFoundException e) 里——这非法。
- ✅ 正确：不同继承树的异常，如
SQLException | IOException - ❌ 错误：父子类共存，如
Exception | RuntimeException或IOException | EOFException（EOFException是IOException的子类） - ⚠️ 注意：
catch中的异常变量e类型是所有列出异常的**最小公共父类型**（通常是Throwable或Exception），无法调用子类特有方法
try {
readFile();
executeQuery();
} catch (SQLException | IOException e) {
// e 的静态类型是 Exception，不能直接调用 SQLException.getSQLState()
logError(e);
}
Java 7 之前只能用多个独立 catch 块
老版本 Java（6 及更早）不支持 | 语法，必须显式写出多个 catch 块。顺序很重要：子类异常必须写在父类前面，否则编译失败 —— 因为后面的 catch 永远不会执行到。
- ✅ 正确顺序：
FileNotFoundException→IOException→Exception - ❌ 错误顺序：
IOException在FileNotFoundException前面 → 编译报错exception java.io.FileNotFoundException has already been caught - ? 即使你只关心日志格式差异，也得按继承顺序排，不能靠“逻辑优先级”随意调整
try {
new FileInputStream("config.txt");
} catch (FileNotFoundException e) {
// 必须放最前
System.err.println("配置文件不存在：" + e.getMessage());
} catch (SecurityException e) {
// 和 IOException 无继承关系，位置可灵活
System.err.println("无访问权限");
} catch (IOException e) {
// 父类放后面
System.err.println("IO 错误：" + e.getMessage());
}
catch 多异常后无法区分具体类型，需用 instanceof 补救
用 | 写法虽然简洁，但丢失了异常类型上下文。如果不同异常需要不同处理逻辑（比如重试策略只对网络异常生效），就不能只靠一个 catch 块完成。
立即学习“Java免费学习笔记（深入）”；
- ❌ 不要这样写：
catch (IOException | SQLException e) { if (e instanceof SQLException) { ... } }—— 显得冗余且易错 - ✅ 更清晰的做法：拆成两个
catch，或在多异常catch内部用instanceof明确分支（仅当逻辑高度相似时才考虑） - ⚠️ 注意：
instanceof判定的是运行时类型，安全；但不要对Throwable或Exception直接判，应限定到你声明捕获的几个具体类型
catch (IOException | SQLException e) {
if (e instanceof SQLException) {
handleDatabaseFailure((SQLException) e);
} else if (e instanceof IOException) {
handleNetworkOrFileFailure((IOException) e);
}
}
别忽略 try-with-resources 和多异常捕获的交互影响
使用 try-with-resources 时，如果资源关闭过程抛出异常，而 try 主体也抛出异常，JVM 会把关闭异常作为 suppressed exception 附加到主异常上。此时若用多异常捕获，可能掩盖真正的问题源头。
- 例如：读文件时抛
IOException，同时BufferedReader.close()抛另一个IOException—— 主异常的getSuppressed()里才有第二个 - ⚠️ 多异常捕获本身不改变 suppressed behavior，但容易让人误以为“只有一种异常发生”，从而漏查资源清理环节的问题
- ? 日志时建议显式打印
e.getSuppressed()，尤其在调试连接池、文件流、HTTP 客户端等场景
实际开发中，越想简化异常处理，越要小心类型擦除和上下文丢失带来的隐性成本。
