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免费学习笔记（深入）”；
- 捕获
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）不能出现在异常消息中，否则可能被日志系统明文留存
catch当成“错误已解决”的信号，而实际上它只是错误处理的起点。 
