CheckedException 仅强制编译期检查，实际风控效果弱；真正有效的风险控制在于异常可恢复性判断、上下文决策能力及拦截点前移（如Optional、Builder校验、熔断重试等）。
Java 中的 CheckedException 无法“强制”调用者处理风险——它只能强制编译期检查，而绕过手段太多，实际风控效果很弱。
为什么 try-catch 或 throws 并不等于风险被真正处理
CheckedException 的设计初衷是让开发者“看见”可能出错的操作（如 FileInputStream 构造、Thread.sleep()），但编译器只认语法结构，不认语义质量：
- 常见写法
catch (IOException e) { e.printStackTrace(); }—— 日志没进监控，异常被静默吞掉 - 直接抛给上层
throws IOException，结果一路往上甩到main或 Servlet 入口，最终变成 500 错误页 - 用
try-with-resources管理资源，但没校验业务状态（比如文件存在但内容为空）
真正起作用的不是声明，而是异常类型的设计和上下文约束
要让 CheckedException 发挥作用，关键在两点：异常是否可恢复、调用方是否有足够信息做决策。例如：
-
SQLException是 checked，但多数业务代码根本不该 catch 它——连接池、事务框架已封装重试与回滚逻辑 -
ParseException（来自SimpleDateFormat.parse()）是 checked，但现代应用应改用LocalDateTime.parse()（unchecked），配合输入校验前置 - 自定义
InsufficientBalanceException extends Exception只有在支付服务里明确定义了“查余额 → 判定 → 补充资金 → 重试”闭环时，才值得设为 checked
比 throws 更有效的风险控制手段
与其依赖编译器强制，不如把风险拦截点前移：
- 用 Optional
替代可能返回 null 的 IO 结果（如 Optional<path> findConfigFile()</path>），把“找不到”的语义显式暴露给调用方 - 用 Builder 模式做构造时校验：
new HttpClient.Builder().timeoutMs(5000).build()在build()里抛IllegalArgumentException（unchecked），避免无效实例流传 - 对网络调用，用 Resilience4j 的
CircuitBreaker+RetryConfig统一兜底，而不是让每个 service 方法都声明throws IOException - 静态检查工具如 ErrorProne 可以识别
catch (Exception e)这类宽泛捕获，并提示“应捕获更具体的子类或重新抛出”
CheckedException 最容易被忽略的一点：它会让开发者产生“我已经处理了异常”的错觉。真正的风险控制不在编译能否通过，而在每次 throw 之前是否问过——这个异常发生时，当前上下文有没有能力、有必要、有责任去响应？
