jdk 7 引入的多异常捕获语法允许在同一个 catch 块中处理多种不同类型的异常，通过管道符 | 分隔异常类型。使用这种语法时，编译器会自动将捕获的异常参数隐式声明为 final，这意味着在 catch 块内部无法对该变量重新赋值。这种做法不仅减少了重复代码，还避免了因多个 catch 块逻辑相同而导致的维护困难。
多异常捕获的基本用法与限制
在 JDK 7 之前，如果一段代码可能抛出 IOException 或 SQLException，且处理逻辑相同，开发者通常需要写两个独立的 catch 块。JDK 7 之后，可以将它们合并为一个 catch (IOException | SQLException e)。需要注意的是，这里的异常类型不能具有继承关系，例如不能同时捕获 Exception 和 RuntimeException，因为子类会被父类覆盖，导致编译错误。此外，由于参数 e 是 final 的，如果在块内尝试 e = new Exception() 会引发编译失败。
try {
// 模拟可能抛出不同异常的代码
throw new IOException("IO Error");
} catch (IOException | SQLException e) {
System.out.println("Caught: " + e.getMessage());
}
上述代码展示了基本的合并捕获方式。当 throw new IOException() 执行时，程序进入该 catch 块并打印消息。如果改为抛出 SQLException，同样会被捕获。若尝试捕获具有父子关系的异常，如 catch (Exception | RuntimeException e)，编译器会报错，提示“exception type Exception is already caught by the previous catch clause”。
与传统多 Catch 块的对比及性能影响
传统写法需要为每种异常编写单独的 catch 块，即使内容完全一致。新语法在字节码层面并没有显著的性能提升，它主要是一种语法糖，旨在提高代码的可读性和简洁性。在旧版本中，JVM 可能会为每个 catch 块生成额外的异常表项，而新语法将这些表项合并，使得异常表更紧凑，但运行时开销几乎可以忽略不计。关键在于，新语法强制要求异常参数不可变，这有助于防止在异常处理过程中意外修改异常对象的状态，从而保持日志记录的准确性。
立即学习“Java免费学习笔记（深入）”；
try {
// 模拟操作
} catch (IOException e) {
handle(e);
} catch (SQLException e) {
handle(e); // 重复调用
}
// JDK 7+ 写法
try {
// 模拟操作
} catch (IOException | SQLException e) {
handle(e); // 单一入口
}
对比两段代码，第二段明显更简洁。在处理函数 handle() 时，无论传入的是哪种具体异常，逻辑都是统一的。如果使用旧写法，一旦需要修改处理逻辑，必须同时修改两处，容易遗漏。新语法确保了所有被捕获的异常都经过同一段逻辑处理，降低了出错概率。虽然性能差异微乎其微，但在大型项目中，减少重复代码带来的维护收益远大于潜在的微小性能变化。
基于 finally 块中资源清理的具体问题
在使用多异常捕获时，常有人担心是否会影响 finally 块中的资源清理逻辑。实际上，finally 块的执行不受 catch 块数量的影响，只要 try 块中发生异常，无论是被哪个 catch 捕获，finally 都会执行。然而，如果需要在 finally 中访问异常信息，需要注意 finally 块中定义的变量作用域。通常建议在 try 外部定义资源，或在 catch 中记录日志后，在 finally 中统一关闭资源。若 finally 中也抛出异常，它会掩盖 try 或 catch 中的原始异常，这在多异常场景下同样适用，需确保资源关闭逻辑健壮。
Connection conn = null;
try {
conn = getConnection();
// 操作
} catch (SQLException | IOException e) {
log.error("Error", e);
} finally {
if (conn != null) {
try { conn.close(); } catch (SQLException ignored) {}
}
}
在上述示例中，即使发生了 IOException，finally 块依然会检查并关闭数据库连接。这种模式确保了资源的正确释放，无论异常类型如何。值得注意的是，如果 conn.close() 抛出异常，它不会改变主流程中捕获到的异常类型，但会替换掉当前的异常堆栈，除非使用 Java 7 的 suppressed exceptions 机制（此处不展开）。核心点是，多异常捕获并不干扰 finally 的执行顺序和资源管理策略，开发者只需关注异常类型的统一处理即可。
