受检异常是编译期契约而非强制加锁，用于显式建模外部依赖的不确定性；适用于可预见且可恢复的失败（如IO、SQL异常），需try-catch或throws处理，空catch、泛化捕获、盲目throws属典型误用。
受检异常不是“强制加锁”，而是编译期的契约提醒
Java 设计受检异常（Checked Exception）的根本目的，不是为了给开发者添麻烦，而是把「外部依赖可能失败」这件事，从运行时黑箱提前拉到编译期白板上——它强制你在写代码时就回答一个问题：如果文件读不了、数据库连不上、网络超时了，你的程序打算怎么办？
这不是对“bug”的纠错，而是对“环境不确定性”的显式建模。比如调用 FileInputStream 构造函数会抛出 FileNotFoundException，编译器拦住你，不是说“你代码写错了”，而是说“这个文件是否存在，不归你代码控制，你得想好 fallback 路径”。
- 它只作用于继承自
Exception但**不继承RuntimeException** 的异常类型 - 典型代表：
IOException、SQLException、ParseException、InterruptedException - 如果你不
try-catch或不throws，编译直接报错：Unhandled exception type XXXException
什么时候该用受检异常？关键看“能否预见 + 是否可恢复”
受检异常适用于那些调用方大概率能预知、且有合理手段应对的失败场景。它的存在，本质是 API 设计者和调用者之间的一份轻量级协议。
-
适合场景：文件操作（
readLine()可能因磁盘满失败）、数据库查询（executeQuery()可能因连接断开失败）、日期解析（SimpleDateFormat.parse()可能因格式不对失败） -
不适合场景：空指针（
NullPointerException）、数组越界（ArrayIndexOutOfBoundsException）——这些是逻辑缺陷，该修复代码，不该靠 catch 来兜底 - 注意：
InterruptedException是个特例：它表示线程被中断，属于“协作式取消”信号，必须响应（通常要恢复中断状态或退出），不是随便吞掉的
为什么很多人反感受检异常？常见踩坑点
反感往往来自误用，而非设计本身。最典型的三个反模式：
立即学习“Java免费学习笔记（深入）”；
-
空 catch 块：写个
catch (IOException e) { }，异常被静默吞掉，日志不打、提示没有、状态不重置——这比不加 try-catch 还危险 -
泛化捕获：用
catch (Exception e)拦下所有异常，结果把本该崩溃的NullPointerException也一起掩盖了 -
盲目 throws 向上传递：在每一层都加
throws IOException，最后堆到main方法里再 throw，等于把责任踢给 JVM，没解决任何问题
更隐蔽的问题是：当业务逻辑嵌套多层（比如 Service → DAO → JDBC），一个底层的 SQLException 如果原样 throws 上来，上层根本不知道怎么处理——这时候应该封装成业务语义明确的自定义受检异常，如 OrderLockFailedException。
现代 Java 开发中，受检异常还值得坚持吗？
答案取决于上下文。Spring 等主流框架大量使用运行时异常（DataAccessException 继承 RuntimeException），是因为它把“数据访问失败”视为不可恢复的系统问题，而不是用户可预期的流程分支；而像 NIO 的 AsynchronousFileChannel 则完全回避受检异常，改用 CompletionHandler + 回调处理错误。
所以真正重要的不是“用不用”，而是是否让异常语义匹配真实控制力边界：
- 如果你能重试、降级、提示用户重填、切换备用源——那这个失败就值得用受检异常暴露出来
- 如果你什么都做不了，只能记录日志并告警——那它更适合作为运行时异常，由全局异常处理器统一拦截
- Java 8+ 的
Optional和函数式接口（如Supplier+ 自定义包装）正在提供替代方案，但它们不改变核心原则：错误路径必须显式表达，不能靠运气躲过
最容易被忽略的一点是：throws 不是免责声明，而是调用契约的一部分；而 catch 之后不做任何事，等于签了字却没读条款。
