Java异常处理不是状态恢复而是流程重定向：catch执行完后控制流转向后续代码，但不会回滚已执行操作；能否继续运行取决于资源可用性与状态一致性，需手动设计补偿逻辑确保对象处于可预期状态。
Java 没有“异常恢复机制”——catch 块执行完后程序继续向下运行，但这不等于“恢复异常发生前的状态”，更不是像某些语言（如 Common Lisp）那样支持重启（restart）或回溯式恢复。能否继续执行，取决于你如何处理异常、资源是否仍可用、状态是否一致。
为什么 catch 之后程序能继续运行？
因为 Java 的异常是“中断型”的：抛出异常会终止当前执行路径，但只要被 catch 捕获并处理完毕，控制流就自然回到 catch 块之后的代码（或 finally 后）。这不是“恢复”，而是“流程重定向”。
-
try中抛出NullPointerException→ 立即跳转到匹配的catch→catch执行完 → 继续执行catch后面的语句 - 若未被捕获，异常向上冒泡，最终可能终止线程（如
main线程中未捕获的异常会导致 JVM 退出） - 没有隐式状态回滚：
catch不会自动撤销try中已发生的赋值、IO 写入、数据库插入等操作
常见误以为“已恢复”却实际出错的场景
很多开发者在 catch 里只打印日志或吞掉异常，就认为“程序恢复了”，结果后续逻辑因状态异常而失败。
- 文件读取失败后，忽略
inputStream为null，后续调用read()触发新的NullPointerException - 数据库事务中部分 SQL 失败，
catch了但没rollback()，接着提交，导致数据不一致 - 网络请求超时后，重试逻辑缺失或重试条件未重置（如计数器没清零、连接对象已关闭）
- 集合遍历时删除元素引发
ConcurrentModificationException，catch住但迭代器已失效，继续next()报错
真正可控的“恢复行为”要靠手动设计
所谓“恢复”，本质是你自己定义的补偿动作，比如重试、降级、重置状态、切换备选路径。
立即学习“Java免费学习笔记（深入）”；
- 用
while+ 有限重试：捕获IOException后等待 100ms 再试，最多 3 次 - 提供默认值：
catch (NumberFormatException e) { value = 0; }，确保后续计算不中断 - 显式清理资源：在
catch或finally中调用close()、unlock()、reset() - 切换策略：HTTP 调用失败时，改查本地缓存；缓存也无则返回兜底 JSON 字符串
- 注意
try-with-resources自动关闭资源，但不解决业务逻辑中断后的状态一致性问题
关键不在“能不能继续执行”，而在“继续执行时，对象是否处于可预期状态”。异常之后的代码，必须假设前置步骤可能未完成、部分生效或已破坏不变量——这是最容易被跳过的检查点。
