异常分支结构决定程序能否恢复：checked exception强制处理以支持可预期恢复；unchecked exception默认不恢复，反映逻辑缺陷；error不可恢复，属系统级崩溃；自定义异常通过继承关系传递恢复意图。

Exception（异常）的分支结构直接影响程序能否从错误中恢复。关键不在“是否抛出异常”，而在于异常类型决定了程序员必须如何响应——是强制处理、可选择忽略，还是只能终止流程。

Checked Exception 强制恢复路径

Java 中的 checked exception（如 IOException、SQLException）在编译期就被要求处理。这本质上是在契约层面规定：该错误大概率可预期、可干预、可恢复。

• 调用方必须用 try-catch 捕获并给出具体应对逻辑（比如重试、降级、换数据源）
• 或向上声明 throws，把恢复责任明确移交上层
• 例如读取配置文件失败时，可 fallback 到默认配置，这就是典型的可恢复行为

Unchecked Exception（RuntimeException）默认放弃恢复

运行时异常（如 NullPointerException、ArrayIndexOutOfBoundsException）不强制捕获，因为它们通常反映程序逻辑缺陷，而非外部不确定性。

• 捕获它们往往掩盖真正问题，不如让程序快速失败并修复代码
• 若真要恢复（如用户输入导致的 NumberFormatException），应提前校验，而非依赖 catch
• 强行 try-catch 运行时异常容易造成“吞异常”、状态不一致等更严重后果

Error 及其子类：不可恢复的系统级崩溃

Error（如 OutOfMemoryError、StackOverflowError）代表 JVM 层面的严重故障，程序自身已失去稳定运行基础。

• 不应尝试捕获和恢复，因为此时对象状态、线程安全、资源一致性都可能已损坏
• 极少数场景（如容器/框架）可能捕获 Error 做日志记录或优雅关闭，但绝不是为了“继续执行业务逻辑”
• 试图恢复 Error 类似于发动机爆炸后还想踩油门

自定义异常的设计暗示恢复意图

你定义的异常类型本身就是一种接口语义。命名和继承关系会向调用方传递明确信号：

• 继承 Exception → “这个错你应该处理，有办法救”
• 继承 RuntimeException → “这是你写错了，别 catch，去改代码”
• 包含 retryable / fallback / timeout 等字段或方法 → 明确支持某种恢复策略

异常分类不是语法装饰，而是对“错误本质”的建模。选错分支，轻则让恢复逻辑形同虚设，重则把 bug 掩饰成正常流程。