Java中try-catch不能恢复程序执行流，异常后原try块中异常点之后代码永不执行，catch结束后续执行从catch末尾或finally后开始，所谓“恢复”需手动重试或递归。

Java中try-catch不能“恢复”程序执行流

Java的异常处理机制本质是中断式控制流转移，catch块执行完后，程序不会自动跳回抛出异常的位置继续执行。所谓“恢复”，其实是开发者手动安排后续逻辑，不是JVM自动回滚或续跑。

常见误解是：在catch里修正了变量、重试了操作，就等于“从异常点恢复”。但实际是——异常发生后，原方法栈帧已部分销毁，try块中异常点之后的代码永远不会再执行。

• try块中第5行抛出NullPointerException → 第6行及之后语句被跳过
• catch执行完 → 程序从catch末尾或finally之后继续，不会回到第6行
• 若需“重试”，必须显式用while循环或递归调用，且要确保状态可重入

何时该用catch，何时该用throws

选择取决于责任边界：谁有能力处理这个异常，谁就该捕获；否则应向上声明，让调用方决定。

例如读取配置文件失败：FileNotFoundException对工具类来说无法自救，应throws；但对主程序而言，可以弹默认配置或退出，就该catch。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

立即学习“Java免费学习笔记（深入）”；

• 捕获RuntimeException子类（如IllegalArgumentException）通常意味着修复输入或逻辑，而不是掩盖问题
• 捕获IOException后不做任何处理（空catch），大概率导致数据不一致或静默失败
• 在Spring等框架中，常将检查型异常包装为RuntimeException，避免强制throws污染API

finally里修改返回值的陷阱

当try或catch中有return，而finally也含return或修改基本类型返回变量时，结果会被覆盖——这是Java字节码层面的确定行为，不是bug。

public static int getValue() {
    int x = 0;
    try {
        return x; // 此处返回值已确定为0
    } finally {
        x = 1;
        return x; // ✅ 最终返回1，覆盖try中的return
    }
}

• 如果finally没有return，但修改了引用类型的字段，调用方仍能看到变化（如list.add()）
• 基本类型变量在return时已被拷贝，finally中改它不影响返回值；但加了return语句就会截断流程
• 避免在finally里写return，除非你明确需要覆盖原返回值

异常链与日志记录的关键实践

用throw new RuntimeException("业务失败", cause)保留原始异常栈，比printStackTrace()或吞掉异常有用得多。但要注意：日志中重复打印同一异常链会污染排查线索。

• SLF4J等主流日志框架默认输出完整异常链，无需手动e.printStackTrace()
• 在catch中重新抛出时，优先用构造函数传入cause，而非拼接字符串
• 不要在每层都log.error("", e)——只在最外层或边界处记录一次，否则日志爆炸且难以定位根因
• 敏感信息（如密码、token）不能出现在异常消息中，否则可能被日志系统明文留存

Java异常机制的复杂点不在语法，而在对控制流、资源生命周期和错误边界的理解。最容易被忽略的是：把catch当成“错误已解决”的信号，而实际上它只是错误处理的起点。