关键不在于“能不能 catch”，而在于“该不该主动 catch”及“怎么响应才合理”：受检异常编译强制处理，代表外部可变问题（如IOException），应恢复或降级；运行时异常编译不检查，反映内部逻辑缺陷（如NullPointerException），应预防而非捕获。
区分运行时异常和编译时受检异常的捕获，关键不在于“能不能 catch”，而在于“该不该主动 catch”以及“怎么响应才合理”。Java 的设计意图已经通过编译机制给出明确信号：一个异常是否强制你处理，本质上是在告诉你——它属于外部可变环境问题，还是内部逻辑缺陷。
看编译器是否报错：最直接的判断依据
写一段可能抛异常的代码，不加 try-catch，也不加 throws：
- 编译失败（提示 “unreported exception XXX; must be caught or declared”）→ 是受检异常，比如 IOException、SQLException
- 编译通过，但运行时报错（如控制台打印 NullPointerException 堆栈）→ 是运行时异常，比如 NullPointerException、ArrayIndexOutOfBoundsException
查继承关系：本质决定行为规范
打开异常类源码或在 IDE 中 Ctrl+点击类名：
- 父类是 RuntimeException 或其任意子类 → 运行时异常（如 IllegalArgumentException、IllegalStateException）
- 父类是 Exception，但**不是** RuntimeException 的后代 → 受检异常（如 FileNotFoundException 是 IOException 子类，IOException 继承 Exception 但不继承 RuntimeException）
按语义决定捕获策略：不是技术问题，而是设计选择
受检异常代表“程序之外的事出了问题”，比如磁盘没文件、网络断了、数据库连不上。这类问题大概率会发生，且往往可以恢复或降级处理：
立即学习“Java免费学习笔记（深入）”；
- 对 IOException，应考虑重试、换路径、提示用户重新上传
- 对 InterruptedException，捕获后必须调用
Thread.currentThread().interrupt()恢复中断标记 - 避免空 catch 或只打日志却不做任何业务响应
运行时异常代表“代码写错了”，比如传了 null、下标越界、参数明显非法。这类问题本不该发生，靠捕获兜底只是掩盖缺陷：
- 优先在入参处校验（Objects.requireNonNull、范围检查）、用 Optional 封装可能为空的返回值
- 若必须捕获（如解析第三方数据时无法保证输入质量），应记录完整堆栈并触发告警，而不是静默吞掉
- 不要写
catch (NullPointerException e)来替代判空逻辑
自定义异常时选对基类：向调用方传递明确契约
继承哪个父类，就是在告诉使用者：“你得负责处理”还是“你用错了，赶紧改”：
- 业务上需要调用方决策的失败（如“库存不足”“支付超时”）→ 继承 Exception，强制对方 try 或 throws
- 明显是调用方传参错误或状态误用（如传了 -1 的订单 ID、用了已注销的 token）→ 继承 RuntimeException，靠测试和文档约束，不污染方法签名
- 切忌为图省事全用 RuntimeException，也别把所有业务失败都做成受检异常导致调用链层层 throws
