java 7多异常捕获要求异常类型互不继承且均为检查型异常，| 合并仅提升代码简洁性，不优化性能，需避免滥用导致可读性下降和维护困难。
Java 7多异常捕获：用 | 合并 catch 块的前提条件
必须是互不继承的检查型异常（Exception 及其子类），且不能有父子关系。比如 IOException 和 SQLException 可以合写，但 IOException 和 FileNotFoundException 不行——后者是前者的子类，编译器会报错 Alternative catch not permitted: FileNotFoundException is a subclass of IOException。
常见误用场景：把 RuntimeException 和检查型异常混在一起，比如 catch (IOException | IllegalArgumentException e) —— 这合法，但毫无意义，因为 IllegalArgumentException 是运行时异常，本来就不强制捕获；更关键的是，它会让异常处理逻辑变得模糊，掩盖真正需要显式处理的检查异常。
- 只适用于 Java 7+，且编译和运行环境都得支持（
source=1.7,target=1.7） - 合并后的异常变量
e类型是各异常的最近公共父类（通常是Exception），不能调用子类特有方法 - 如果需要区分处理，仍得用
if (e instanceof ...)判断，此时不如拆成多个catch
怎么写才不会触发 “multi-catch parameter is implicitly final” 编译错误
Java 7 规定多异常捕获中的参数自动视为 final，你不能在 catch 块里给它重新赋值，比如 e = new RuntimeException() 会直接编译失败。
这个限制不是 bug，而是设计使然：避免在异常传递链中意外覆盖原始异常引用，影响调试和日志准确性。
立即学习“Java免费学习笔记（深入）”；
- 不要试图修改
e的引用，如e = new MyException(e) - 若需包装异常，用新变量：
MyException wrapped = new MyException("wrap", e) - 若要记录后抛出，用
throw new RuntimeException(e)，而不是先改e再throw e
性能和字节码层面：多 catch 真的比单 catch 快吗？
不快。生成的字节码里，每个异常类型仍对应独立的 exception table 条目，和分开写多个 catch 块几乎一致。JVM 不会因为语法上“合并”就做任何优化。
它的价值纯在代码简洁性与可维护性：减少重复的资源清理逻辑、避免因复制粘贴导致的修复遗漏。
- 编译后，
catch (IOException | SQLException e)和两个独立catch占用的字节码量基本相同 - 异常匹配顺序仍是自上而下，第一个匹配的类型生效，和传统
catch链行为一致 - IDE（如 IntelliJ）对多异常捕获的重构支持较弱，重命名或提取方法时容易漏掉某个分支
实际项目中该不该用？看这三点再决定
不是所有“能用”的语法糖都该用。多异常捕获适合那些语义上等价、处理方式完全一致的异常场景，比如统一关闭连接、记录日志、转成统一业务异常。
一旦出现“这个异常要重试，那个要告警，另一个要忽略”，就该立刻拆开——强行合并只会让逻辑藏在一堆 if/else 里，比原来更难读。
- 团队成员对 Java 7+ 特性熟悉度不高时，优先用传统写法，降低认知成本
- 项目还在兼容 Java 6（哪怕只是遗留模块），那就彻底禁用，连编译都过不去
- 静态检查工具（如 SonarQube）可能对多 catch 的空块或泛型异常警告更宽松，容易漏掉未处理逻辑
最常被忽略的一点：异常类型列表过长（比如超过 3 个）时，可读性断崖下跌。与其写 catch (AException | BException | CException | DException | EException e)，不如抽一个私有方法封装共用逻辑，再分别 catch。
