java多catch中异常类不得存在继承关系，根本原因是编译器必须静态确定唯一匹配路径：若a是b的子类，则catch(a|b)会产生类型歧义，编译报错；同理，多个catch块须子类在前、父类在后，否则子类块不可达。
Java 多 catch 语法中禁止异常类存在继承关系，根本原因在于**编译器必须保证异常处理路径唯一、可静态判定**。这不是风格建议，而是语言层面的强制约束，违反即编译失败。
为什么父子异常不能共存于同一 catch 块（用 |）
Java 7+ 的 catch (A | B e) 要求 A 和 B 必须互不继承。因为 JVM 在编译期就要确定：当抛出某个异常实例时，它是否属于这个多异常列表中的“某一个”，且只能匹配其中唯一一个类型。
- 如果写
catch (IOException | FileNotFoundException e)，而FileNotFoundException是IOException的子类，那么所有FileNotFoundException实例也天然属于IOException—— 编译器无法区分“该走哪个分支”，逻辑上产生歧义 - 编译器直接报错：
error: alternatives in a multi-catch statement cannot be related by subclassing - 合法示例只有跨继承树的组合，比如
SQLException | IOException（二者都继承Exception，但彼此无继承）
为什么多个独立 catch 块必须子类在前、父类在后
多个 catch 块按书写顺序从上到下依次匹配，JVM 取第一个能捕获当前异常的块执行。顺序错误会导致部分 catch 永远不可达。
- 写成
catch (Exception e)在前，catch (NullPointerException e)在后 → 编译报错：exception NullPointerException has already been caught - 因为
NullPointerException是RuntimeException的子类，而RuntimeException又是Exception的子类，前面已全覆盖 - 正确顺序必须是具体到宽泛：例如
FileNotFoundException→SecurityException→IOException→Exception
异常变量 e 的类型受限，不能调用子类特有方法
即使你写了 catch (SQLException | IOException e)，变量 e 的静态类型也不是 SQLException 或 IOException，而是它们的最小公共父类——这里是 Exception。
- 你不能直接调用
e.getSQLState()（SQLException特有）或e.getCause()（虽Exception有，但若想用子类更精确的方法，必须转型） - 如需差异化处理，得用
instanceof判断后再强制转换：if (e instanceof SQLException) { ((SQLException)e).getSQLState(); } - 这说明多异常捕获本质是“统一入口、分叉处理”，不是类型自由切换
兜底异常不能滥用 Exception 或 Throwable
把 Exception 或 Throwable 放在最前或单独使用，会掩盖真实问题，破坏异常分类的价值。
- 它会让本该被明确识别和恢复的业务异常（如
ValidationException）被笼统吞掉 - 调试时丢失上下文，日志中只剩泛泛的 “Exception occurred”，无法定位根因
- 正确做法是：先捕获具体异常（如
IllegalArgumentException），再用Exception做最后兜底，且兜底块中至少要记录完整堆栈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
