java异常捕获必须按子类到父类顺序排列，否则父类如exception会提前捕获所有子类异常，导致后续catch块不可达而编译失败；这源于异常匹配采用首个可匹配原则，类似if-else链。
因为 Java 编译器会按 catch 块从上到下的顺序匹配异常类型，一旦某个 catch 参数能接收当前抛出的异常（即该异常是其声明类型的实例或子类），就立即执行该块，后续 catch 不再检查。如果把 Exception 这种宽泛的父类写在前面，它就能捕获所有继承自它的子类异常——比如 IOException、SQLException、IllegalArgumentException 等。结果就是，后面那些更具体的 catch 块永远没机会运行，变成“不可达代码”。
编译器直接拒绝这种写法
Java 把“不可达代码”视为语法错误，不是警告，而是编译失败。IDE 会标红并提示类似：
- Unreachable catch block for IOException
- This exception is already caught by the preceding catch block
本质是类型匹配机制决定的
异常匹配不是靠“最精确匹配”，而是“第一个能匹配上的”。这和 if-else if 链类似：只要第一个条件为真，后面的分支就不看了。
-
Exception是几乎所有受检和非受检异常的祖先（除Error和Throwable直接子类外） - 所以它就像一把“万能钥匙”，插进锁孔就转开了，根本不会留给更专用的钥匙（如
FileNotFoundException）出场机会
不只是 Exception，所有父子关系都适用
这个规则不限于 Exception。任何存在继承关系的异常类型，子类都必须写在父类前面：
- ✅ 正确：
catch (NullPointerException e)→catch (RuntimeException e) - ❌ 错误：
catch (RuntimeException e)→catch (NullPointerException e)（编译不通过） - ✅ 同级异常（无继承关系）顺序可任意，如
IOException和SQLException
实际影响不止编译，还有逻辑缺陷
即使某些旧版本或特殊配置绕过编译检查（极少见），运行时也会丢失对具体异常的处理能力：
- 无法针对
SQLTimeoutException做重试，只能笼统记日志 - 无法区分
IllegalArgumentException（参数错）和IllegalStateException（状态错），导致修复方向偏差 - 调试时看不到原始异常类型，排查成本陡增
