Checked异常是Java编译器强制处理的异常，代表运行时无法通过修改代码消除的外部风险，如IOException、SQLException等，必须try-catch或throws声明。
Checked异常是Java编译器强制你“看见并回应”的异常——不处理，代码直接编译失败。
它不是bug，也不是逻辑错，而是系统在提醒你：“这事外部说了算，你得想好万一出问题怎么办”。
为什么编译器死盯着IOException、SQLException不放？
因为它们代表的是程序**无法靠改代码就消除**的风险：磁盘没文件、网络断了、数据库挂了、日期格式用户乱输……这些不是写错了，是运行时真实会发生的客观条件。
-
IOException、SQLException、ParseException、ClassNotFoundException都属于这一类 - 它们继承自
Exception，但**不继承RuntimeException** ——这是编译器识别的关键 - 方法声明里只要写了
throws IOException，调用它就必须：try-catch或在自己签名里继续throws
常见错误：在lambda或Optional里直接抛Checked异常
比如用 SimpleDateFormat.parse() 写进 Optional.map()：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
optional.map(simpleDateFormat::parse) // 编译报错：Unhandled ParseException
原因很直接：Function.apply() 接口没声明抛 ParseException，而Java不允许lambda把Checked异常“漏出去”。
- ✅ 正确做法：在lambda内部捕获并转成Unchecked异常，或封装为返回值（如
Optional.empty()） - ❌ 错误做法：加个空
catch吞掉、或用throws强行往上扔（接口不许） - ⚠️ 注意：
try-with-resources也不能绕过这个限制——资源本身可能抛Checked异常，但你仍得在作用域内处理它
什么时候该用Checked异常？又什么时候该忍住不用？
关键看调用方有没有**合理且常见的恢复路径**。
- ✅ 适合Checked：读配置文件失败 → 可加载默认值；连DB超时 → 可重试或切备用源；解析用户输入日期 → 可提示格式要求
- ❌ 不适合Checked：参数校验失败（如
id <= 0）→ 应抛IllegalArgumentException（Unchecked），这是调用方的错，不该让上层被迫写一堆无意义的try - ⚠️ 混淆高发区：
FileNotFoundException是Checked，但NullPointerException不是——前者你没法保证文件一定存在，后者是你忘了判空
最常被忽略的一点：Checked异常不是用来“证明我处理了”，而是用来推动责任落到真正能决策的地方。底层工具类别 catch 后打日志就完事，那等于把开关焊死了；把它 throws 出去，交到Controller或Service层统一兜底，才符合它的设计本意。
