java异常捕获顺序的核心原则是子类异常必须写在父类异常之前，否则编译直接报错；因java按catch从上到下匹配，父类如exception会提前捕获所有子类异常，导致后续catch块不可达，编译器静态检查报“unreachable catch block”。
Java 异常捕获顺序的核心原则是：子类异常必须写在父类异常之前，否则编译直接报错。这不是运行时陷阱，而是编译期强制约束，背后是 Java 的“更具体异常优先匹配”设计逻辑。
catch 顺序错误会直接编译失败
Java 要求 catch 块按“从具体到宽泛”的顺序排列。例如：
- ✅ 正确：先 catch
IOException，再 catchException - ❌ 错误：先 catch
Exception，再 catchIOException→ 编译器报错 “exception IOException has already been caught”
因为 IOException 是 Exception 的子类，一旦父类异常已覆盖所有可能，后续子类 catch 就永远无法执行，编译器会拒绝这种冗余代码。
多 catch 中的常见逻辑陷阱
即使语法合法，仍可能因逻辑疏忽导致异常被意外吞没或误处理：
- 同一个 try 块中，多个 catch 捕获有继承关系的异常（如
SQLException和RuntimeException），需确认它们无父子关系，否则仍会触发编译错误 - 使用多 catch（
catch (IOException | SQLException e)）时，异常类型必须互不兼容（即没有继承关系），否则编译不通过 - 若在 catch 中仅写
e.printStackTrace()或空 catch，看似“捕获了”，实则掩盖问题——这是面试常问的“伪处理”陷阱
finally 执行时机与 return 冲突
很多人忽略 finally 在 return 语句前的执行优先级：
- try 或 catch 中有 return，JVM 会先记录返回值，再执行 finally；若 finally 中也有 return，它会覆盖原返回值
- finally 中抛出异常，会压制 try/catch 中的异常（包括已 catch 并处理的异常）
- 建议：finally 中只做资源清理（如 close()），避免 return 或 throw
受检异常 vs 非受检异常的捕获盲区
面试常考是否理解“编译器强制检查”的边界：
-
Exception及其子类（除RuntimeException及其子类）是受检异常，必须 try-catch 或 throws，否则编译失败 -
RuntimeException（如NullPointerException、ArrayIndexOutOfBoundsException）是非受检异常，可不捕获，但不等于不该处理 - 典型误区：“没写 catch 就不会出错”——运行时照样崩溃；或“加了 catch(Exception e) 就万事大吉”，却忽略了日志缺失、状态未回滚等隐性风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
