catch块必须按子类到父类顺序排列,否则编译报错;Java 7+支持无继承关系的多异常捕获;避免用Exception兜底掩盖问题;finally和try-with-resources总在退出时执行。

catch块必须按异常继承顺序从子类到父类排列
Java编译器会严格检查 catch 块的声明顺序:如果父类异常(如 Exception)写在子类异常(如 NullPointerException)前面,后续的子类 catch 就永远无法到达,编译直接报错:exception NullPointerException has already been caught。
这是因为异常匹配是按代码顺序从上到下执行的,一旦某个 catch 的类型能匹配抛出的异常实例(包括其子类),就立即进入该分支,不再继续判断。
- 正确顺序:先写具体异常,再写泛化异常,例如
IOException→Exception - 错误写法:
try { // ... } catch (Exception e) { // ❌ 这里会拦截所有异常,下面的 catch 永远不会执行 } catch (NullPointerException e) { // ⛔ 编译失败:unreachable catch block } - 常见误用场景:IDE自动补全时没注意顺序,或重构时把通用
catch提前了
多个同级异常不能共用一个catch(Java 7+支持多异常捕获但有限制)
Java 7 引入了多异常捕获语法,允许一个 catch 块处理多个互不相关的异常类型,但它们必须是并列关系(即没有继承关系),且用 | 分隔。
- 合法示例:
catch (IOException | SQLException e)—— 两者都继承自Exception,但彼此无继承 - 非法示例:
catch (Exception | RuntimeException e)—— 编译报错,因为RuntimeException是Exception的子类 - 注意:多异常捕获中,
e的静态类型是所有列出异常的**最近公共父类**(通常是Exception或Throwable),所以不能直接调用子类特有方法
不要用Exception或Throwable兜底来掩盖问题
虽然语法允许 catch (Exception e) 或 catch (Throwable t) 放在最后兜底,但实际工程中这是危险信号:
立即学习“Java免费学习笔记(深入)”;
- 它会吞掉本应暴露的编程错误,比如
NullPointerException或ArrayIndexOutOfBoundsException,掩盖逻辑缺陷 - 日志若只打印
e.getMessage(),会丢失堆栈,难以定位问题源头 - 真正需要兜底的场景极少,典型的是顶层线程异常处理器(如
Thread.setDefaultUncaughtExceptionHandler)或主程序入口 - 若必须兜底,请至少记录完整堆栈:
catch (Exception e) { logger.error("Unexpected error occurred", e); // ✅ 记录整个 Throwable }
finally和try-with-resources的优先级高于catch执行时机
多重 catch 只影响异常处理路径的选择,但不影响 finally 或 try-with-resources 的执行时机——它们总会在 try 块退出时运行(无论是否抛异常、是否被 catch 住)。
- 即使某个
catch块里又抛出新异常,finally仍会先执行,再向上抛出新异常 -
try-with-resources的资源关闭等价于隐式finally,同样不受catch顺序影响 - 容易忽略的点:如果
finally里也抛异常,它会覆盖catch中已处理的异常(Java 7+ 会将原异常作为 suppressed exception 附加)
catch 时,最常踩的坑不是语法错误,而是把“能捕获”当成了“该捕获”。异常顺序只是编译器强制的规则,而决定哪些异常该被捕获、如何恢复、是否重抛,才是真正考验设计的地方。










