Java中受检异常是编译器强制处理的Exception子类（不含RuntimeException），需try-catch或throws；典型如IOException、SQLException；应据业务意图合理处理，避免暴露底层细节。
Java中受检异常（Checked Exception）是指编译器强制要求你处理的异常。它不是运行时偶然出错，而是设计上就预见到可能发生、且调用方理应主动应对的“可恢复问题”，比如读文件失败、连数据库超时、类找不到等。
受检异常的核心特征
它继承自 Exception 类，但**不包括 RuntimeException 及其子类**。编译器在编译阶段就会检查：如果某方法可能抛出受检异常，你必须做其中一项——
- 用 try-catch 捕获并处理
- 用 throws 声明抛给上层调用者
- 两者都不做，编译直接报错
常见的受检异常类型
这些不是凭空出现的，都对应真实、可控的外部交互场景：
- IOException：文件读写、网络通信出错（如文件不存在、磁盘满）
- SQLException：数据库操作失败（如SQL语法错、连接中断）
- ClassNotFoundException：动态加载类时类名拼错或不在 classpath 中
- InterruptedException：线程被意外中断（多见于 wait/sleep/join）
怎么正确处理受检异常
不能只为了过编译而随便 catch 或 throws。关键看业务意图：
Excel XLSX Formula Cleanup
下载
诊断并修复涉及公式、命名范围、Power Query 刷新、数据透视表、VBA/宏保存等问题的 Microsoft Excel XLSX 工作簿
立即学习“Java免费学习笔记（深入）”；
- 当前层能解决？比如文件没找到，就创建默认配置 → 用 try-catch 处理
- 当前层无权/无法处理？比如 DAO 层遇到 SQLException，业务层才决定重试还是提示用户 → 用 throws 向上声明
- 别把底层细节暴露出去：避免在 service 层直接 throws SQLException，应包装成自定义业务异常（如 DataAccessException），继承 RuntimeException 更合适
- 资源操作优先用 try-with-resources，自动关闭流，减少 finally 手动释放的出错可能
和非受检异常的区别要点
一句话区分：
- 受检异常 = “你应该知道这事可能发生，并打算怎么应对”（如用户上传的 Excel 格式不对）
- 非受检异常 = “这属于程序 bug 或不可控崩溃，修复代码比捕获更重要”（如调用时传了 null 导致 NullPointerException）
基本上就这些。受检异常不是负担，是 Java 提前帮你把“外部依赖风险”标出来，提醒你补上容错逻辑。
