受检异常是Java中必须在编译期显式处理的异常，继承自Exception但不继承RuntimeException；典型代表有IOException、SQLException、ParseException等，多由外部环境引发且可恢复；设计目的是强制开发者应对可预期的运行时问题，而非增加负担。
受检异常（Checked Exception）是Java中一类必须在编译期显式处理的异常，它继承自
Exception
类，但**不继承自 RuntimeException**。编译器会强制要求：调用可能抛出受检异常的方法时，要么用
捕获，要么在方法签名中用
声明——否则代码无法通过编译。
哪些是典型的受检异常？
它们大多代表**外部环境引发的、可预期且可恢复的问题**，不是代码写错了，而是资源不可用、格式不对或通信失败等客观条件导致的。常见类型包括：
java.io.IOException
及其子类：如
（文件不存在）、
（读到流末尾）、
（网络断连）
java.sql.SQLException
：如
、
，出现在JDBC执行SQL时
java.text.ParseException
：用
解析非法日期字符串时抛出
java.net.URISyntaxException
：构造
对象时传入格式错误的字符串
java.lang.ClassNotFoundException
：动态加载类（如
）时类路径中找不到该类
javax.naming.NamingException
：JNDI查找资源失败，比如查不到配置的数据源名
为什么设计成“必须处理”？
这不是为了增加开发负担，而是提醒开发者：这类问题大概率会在运行时发生，且往往有合理补救方式。例如：
文件没找到 → 可提示用户重新输入路径，或自动创建默认
配置文件
数据库连接失败 → 可重试、切换备用库、降级返回缓存数据
URL格式错误 → 可记录日志并返回友好提示，而不是让整个请求崩溃
典型使用场景与写法
关键原则是：**不掩盖、不忽略、不裸 throw**。推荐做法：
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
立即学习
“
Java免费学习笔记（深入）
”；
在工具类或底层方法中保留 throws，把责任交给上层业务逻辑决定如何应对
在业务入口（如 Controller、Service 方法）做统一捕获，转为用户友好的提示或系统级错误码
涉及资源操作（文件、连接、流）时，配合 try-with-resources 自动释放，避免泄漏
示例：
什么时候不该用受检异常？
如果一个异常本质上反映的是编程错误（比如参数校验失败、状态非法），就该用非受检异常（
、
）。强行用受检异常反而会让调用方疲于应付，违背“可恢复”初衷。另外，现代框架（如 Spring）常将部分受检异常（如 SQLException）包装为非受检异常，也是为了简化 API 使用。
try-catchthrowsFileNotFoundExceptionEOFExceptionSocketExceptionSQLTimeoutExceptionSQLSyntaxErrorExceptionSimpleDateFormat.parse()URIClass.forName("xxx")public String readConfig(String path) throws IOException {
// 不在这里 catch，因为读配置失败的具体应对策略由调用方决定
return Files.readString(Path.of(path));
}
// 调用处（如 Web 接口）
@GetMapping("/config")
public ResponseEntity getConfig() {
try {
return ResponseEntity.ok(readConfig("app.conf"));
} catch (IOException e) {
log.warn("配置文件读取失败", e);
return ResponseEntity.status(500).body("配置服务暂时不可用");
}
} IllegalArgumentExceptionIllegalStateException