Java受检异常是编译期强制处理的Exception子类（非RuntimeException），用于应对可预期的外部风险如I/O、数据库、网络等失败，需try-catch或throws声明，体现契约式编程思想。
Java中的受检异常（Checked Exception）是指那些在编译阶段就必须被显式处理的异常。它不是运行时偶然发生的“bug”，而是设计上就预期可能发生、且调用方理应知晓并应对的外部不确定性——比如读一个可能不存在的文件、连一个可能不通的数据库、加载一个可能缺失的类。编译器会强制你面对它：要么用 try-catch 捕获，要么用 throws 声明抛出，否则代码根本编译不过。
受检异常的核心特征
它继承自 Exception 类，但**不继承自 RuntimeException**。这个继承关系是编译器做检查的依据。只要满足这个条件，Java 就把它归为“必须处理”的一类。
- 编译期强制干预：不是靠文档或约定，而是编译器直接报错，杜绝“忘了处理”
- 代表可控的外部风险：如 I/O 失败、网络超时、SQL 执行异常、类加载失败等，这些不是代码写错了，而是环境或资源出了问题
- 推动责任前移：方法声明抛出受检异常，等于告诉调用者：“这事我搞不定，请你决定怎么兜底”
常见受检异常举例
它们都指向现实世界中容易发生、但程序有能力响应的场景：
-
IOException：文件读写失败、流关闭异常、网络连接中断 -
SQLException：数据库连接失败、SQL 语法错误、事务回滚失败 -
FileNotFoundException：尝试打开一个路径下并不存在的文件 -
ClassNotFoundException：反射时指定的类名在 classpath 中找不到 -
InterruptedException：线程在阻塞状态（如sleep或wait）中被其他线程中断
为什么 Java 要设计受检异常？
这不是为了给开发者添麻烦，而是一种契约式编程思想的体现：
立即学习“Java免费学习笔记（深入）”；
- 避免隐性失败：没有受检机制时，I/O 方法可能默默返回 null 或 -1，调用方若忘记检查，后续逻辑就崩了；受检异常把“出错可能”暴露在方法签名里，无法忽视
- 分离关注点：正常业务逻辑和资源异常恢复逻辑可以解耦。比如打开文件失败，你可以重试、换路径、提示用户，而不是让主流程混杂一堆 if 判断
- 提升 API 可靠性：一个声明了
throws IOException的方法，使用者立刻明白它依赖外部资源，需准备容错策略
使用时的关键提醒
受检异常虽好，但滥用或误用反而降低可维护性：
- 不要把本该由逻辑校验解决的问题包装成受检异常（例如参数为空就抛
IllegalArgumentException是 RuntimeException，不该改成受检） - 避免在底层工具类中过度抛出受检异常，导致上层被迫层层
throws，可考虑包装为更语义化的业务异常（继承Exception） - 捕获后不能只写空
catch{}，至少记录日志或给出明确 fallback 行为，否则等于屏蔽了异常信号
