异常处理后如何控制程序流程？

Java异常处理中的程序流控制远比“出错就停止”复杂得多：只要异常被正确捕获且catch块中未主动throw或return，程序便会继续执行try-catch结构之后的代码；finally几乎总能执行（仅System.exit()或JVM强制终止时被跳过），甚至会覆盖try/catch中的return值；多catch必须严格遵循子类在前、父类在后的顺序，否则编译失败；而看似省事的空catch实则是线上故障的隐形推手——它悄无声息地吞掉异常堆栈、掩盖资源泄漏与逻辑错误，让问题难以复现和定位。掌握这些细节，才能真正写出健壮、可维护、可观测的Java异常处理逻辑。

try-catch 后代码是否继续执行

会，只要没遇到 return、throw、System.exit() 或未捕获的异常，catch 块执行完后程序会继续向下运行到 try-catch 结构之后的语句。

常见误解是“出了异常整个方法就停了”，其实只是当前异常被抛出的那条语句中断，后续能否继续取决于有没有被 catch 住、以及 catch 里做了什么。

• catch 块末尾没有 return，则继续执行 catch 后面的代码
• catch 里主动 throw 新异常，后续代码不执行，异常向上抛
• try 中抛异常但没匹配到任何 catch，则跳过所有 catch 和 finally（如果有且未被中断），直接向外传播

finally 一定会执行吗

绝大多数情况下会，但有两个关键例外：System.exit() 和 JVM 强制终止（如 kill -9）会导致 finally 被跳过。

即使 try 或 catch 中有 return，JVM 也会先把 finally 执行完再返回——注意：如果 finally 里也有 return，它会覆盖前面的返回值。

• try { return 1; } finally { return 2; } → 实际返回 2
• try { int x = 1/0; } catch(Exception e){} finally { System.out.println("here"); } → “here” 一定打印
• 避免在 finally 里写 return，容易掩盖真实逻辑和调试线索

多个 catch 的匹配顺序怎么定

按代码中出现的**从上到下顺序**匹配，且必须遵循“子类在前、父类在后”，否则编译报错：Unreachable catch block。

这是因为 Java 编译器静态检查时，一旦某个 catch 参数类型能捕获后续所有异常，后面的 catch 就永远进不去。

• 正确：catch (NullPointerException e) 在前，catch (RuntimeException e) 在后
• 错误：catch (Exception e) 在前，后面再跟任何 catch 都会编译失败
• 可以合并处理时，用多异常语法：catch (IOException | SQLException e)

异常吞掉（empty catch）为什么危险

空 catch 块（即 catch(Exception e) {}）不是“静默处理”，而是彻底丢弃异常上下文，导致问题无法定位、状态不一致、资源未释放等连锁反应。

典型后果包括：数据库连接泄漏、文件句柄卡死、业务逻辑误判成功、监控完全失焦。

• 至少记录日志：catch (Exception e) { logger.error("failed to process order", e); }
• 如果真要忽略，加明确注释说明原因（比如“兼容旧版空响应”）
• 绝不要用 catch (Throwable t) + 空块，可能吞掉 OutOfMemoryError 这类致命错误

实际线上出问题时，最常被忽略的是 finally 中的副作用和多层嵌套 try-catch 导致的控制流混乱——建议用 IDE 的“Find Usages”查一下项目里有多少个空 catch，再顺手看看 finally 里有没有 return。

今天关于《异常处理后如何控制程序流程？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！