Java 7+ 支持用 | 在单个 catch 中捕获多个互不继承的异常，共享处理逻辑；异常变量类型为各类型的最小公共父类，不可调用子类特有方法，且禁止父子类共存以避免语义冗余与字节码歧义。
Java 7+ 的多异常捕获语法：用 | 分隔多个异常类型
Java 7 引入了在单个 catch 子句中捕获多种异常的语法，前提是这些异常之间不能是父子关系（即不能有继承关系）。编译器会检查并拒绝 catch (IOException | SQLException e) 这类写法中若 SQLException 继承自 IOException（实际不是），但若写成 catch (Exception | RuntimeException e) 就会报错——因为后者是前者的子类。
这种写法本质是让多个异常共享同一段错误处理逻辑，适合「错误恢复方式一致」的场景，比如统一记录日志、关闭资源、返回默认值等。
- 必须使用
final或 effectively final 的异常参数（不能在catch块里重新赋值给e） - 异常变量
e的静态类型是所有列出类型的最小公共父类（如IOException | SQLException→ 编译时类型为Exception） - 无法在块内调用子类特有方法（例如不能直接调用
e.getSQLState()），需先用instanceof判断
try {
doSomething();
} catch (IOException | SQLException e) {
logger.error("I/O or DB error occurred", e);
rollback();
}
为什么不能捕获 Exception 和它的子类？
编译器禁止在同一个 catch 中写 catch (Exception | RuntimeException e)，因为这违反了异常处理的语义层级：子类异常已经被父类覆盖，冗余声明无意义，且可能掩盖意图。
更关键的是，JVM 字节码层面每个 catch 块对应一个异常表条目，而多异常捕获会被编译为多个独立条目（但共享代码偏移），若允许父子类共存，会导致匹配顺序歧义和不可预测的行为。
立即学习“Java免费学习笔记（深入）”；
- 错误示例：
catch (Exception | NullPointerException e)→ 编译失败，提示 “alternative exception types must be disjoint” - 正确替代：把更具体的异常放在前面单独
catch，通用的放后面（传统多catch链） - 如果真需要区分处理，就不要强行合并——多写一行
catch比加运行时判断更清晰、更安全
传统多 catch 链 vs 多异常捕获：选哪个？
两者不是互斥替代，而是不同关注点的工具。多异常捕获解决的是「相同处理逻辑」的重复代码问题；而多 catch 链解决的是「差异化响应」问题。
- 用多异常捕获：日志记录、资源清理、返回兜底值等通用操作
- 用多
catch链：需要重试网络请求（SocketTimeoutException）、解析错误转用户提示（JSONException）、权限异常跳登录页（SecurityException）等 - 性能上无差异：多异常捕获只是语法糖，编译后仍是多个异常表项
- 可混用：一个
try后跟多个catch，其中某个可以是多异常形式
try {
processRequest();
} catch (IOException | SQLException e) {
notifyAdmin(e);
throw new ServiceException("Backend failed", e);
} catch (IllegalArgumentException e) {
// 参数校验失败，不通知 admin，直接返回 400
response.sendError(400, "Invalid input");
}
容易被忽略的兼容性与调试陷阱
多异常捕获是 Java 7+ 特性，但很多团队仍在维护 Java 6 项目（尤其银行、嵌入式旧系统），盲目使用会导致编译失败。另外，IDE 和堆栈跟踪对多异常捕获的支持曾有 Bug，某些老版本 IntelliJ 或 Eclipse 可能无法正确高亮或跳转到具体异常分支。
- 构建脚本中务必确认
sourceCompatibility = 1.7（Gradle）或1.7 - 日志中打印异常时，
e.getClass().getName()仍返回实际抛出的类型（如java.io.FileNotFoundException），不是联合类型 - 单元测试要分别覆盖每种异常路径——不能只测其中一个，就认为多异常捕获逻辑已验证
- 静态分析工具（如 SonarQube）可能误报“异常类型未被处理”，需检查是否遗漏了未列在
catch中的受检异常
真正麻烦的从来不是语法怎么写，而是你得清楚哪几种异常确实该被一视同仁地处理，而不是为了少写两行 catch 把业务语义揉在一起。
