🚀 目录
-
[受检异常 (Checked)：程序员的"白大褂"](#受检异常 (Checked)：程序员的“白大褂”)
-
2.1 为什么编译器非要盯着它？
-
2.2 常见的受检异常有哪些？
-
-
[运行时异常 (Runtime)：程序员的"遮羞布"](#运行时异常 (Runtime)：程序员的“遮羞布”)
-
3.1 为什么编译器不理它？
-
3.2 那些让你抓狂的 NPE 是怎么来的？
-
1. 身世之谜：谁才是"嫡系"？
在 Java 异常家族里，所有的异常都继承自 Exception。
-
运行时异常 ：特指继承自
java.lang.RuntimeException的那些类。 -
受检异常 ：除了
RuntimeException及其子类以外，所有直接继承自Exception的异常。
一句话总结 ：只要你没带 Runtime 这个姓，你就得受编译器的"检阅"。
2. 受检异常 (Checked)：程序员的"白大褂"
生活化场景 ： 就像你进化学实验室必须穿白大褂、戴护目镜。虽然你还没开始做实验，但规则规定："只要存在危险的可能性，你就必须提前做好防御。"
2.1 为什么编译器非要盯着它？
这类异常通常是**"外部环境"**导致的，不是你逻辑写错了就能避免的。 比如：网络断了、硬盘坏了、文件被室友删了。 Java 认为：这些事儿大概率会发生，如果你不提前写好处理逻辑，程序跑着跑着挂了，用户会一脸懵逼。
2.2 常见案例
-
IOException（读写文件出事了） -
SQLException（数据库连接炸了） -
ClassNotFoundException（类找不到了）
3. 运行时异常 (Runtime)：程序员的"遮羞布"
生活化场景： 就像你走在图书馆平坦的地上突然左脚拌右脚摔了一跤。这事儿没人能预见，纯粹是因为你自己**"走路不走心"**。
3.1 为什么编译器不理它？
这类异常通常是**"代码逻辑"**导致的，是可以避免的。 Java 认为：如果你连 a[10]（数组只有 5 位）这种事都要写个 try-catch，那代码就没法看了，满屏都是垃圾代码。 编译器默认你是个合格的程序员，这种低级错误你应该通过完善逻辑来解决，而不是靠抛异常。
3.2 常见案例
-
NullPointerException(NPE)：最经典的，你拿个空对象去调方法。 -
ArrayIndexOutOfBoundsException：数组越界。 -
ClassCastException：类型转换失败。
4. 核心对撞：一张表教你做人
| 特征 | 受检异常 (Checked) | 运行时异常 (Runtime) |
|---|---|---|
| 继承关系 | 直接继承 Exception | 继承 RuntimeException |
| 编译器态度 | 强迫症：不处理不给过 | 佛系：你想写就写，不写拉倒 |
| 处理方式 | try-catch 或 throws | 优化代码逻辑 |
| 发生原因 | 外部环境不可控 | 程序员逻辑漏洞 |
| 大学生比喻 | 进实验室必穿白大褂 | 走路不看路摔个狗吃屎 |
5. 深度思考：到底该抛哪个？
这是很多同学在写自定义异常时的纠结。
-
用 Checked 的时机 ：如果这个异常是调用者可以恢复的。比如用户输错了文件名，你可以抛个异常让他重新输。
-
用 Runtime 的时机 ：如果这个异常是程序严重错误，调用者处理了也没用的。比如数据库配置配错了，或者传入的参数完全不符合逻辑。
6. 面试高频考点演练
Q1：为什么不建议把所有异常都改成 RuntimeException？ 答案 ：因为这样会降低代码的健壮性。Checked Exception 是一种"强制约束"，它提醒后来接手你代码的同学："这里很危险，一定要处理！"
Q2：try-catch 捕获异常后，如果不处理（留空），会有什么后果？ 答案：这叫"异常吞掉"。这是极其恶劣的行为！程序出错了你却装不知道，等到真正出大问题时，你连报错信息都找不到，只能对着屏幕流泪。
7. 结语
写完这篇日记，我终于把那个该死的 IOException 处理好了。 受检异常虽然烦人，但它确实像个严厉的导师，逼着我们去思考代码的各种边界情况；而运行时异常则像面镜子，时刻提醒着我们："代码写得细一点，Bug 就少一点。"
作为大学生的我们：
-
面对 Checked，要耐心写好兜底逻辑。
-
面对 Runtime，要反思自己的逻辑是否严密。
如果你也曾被 NPE 搞到怀疑人生，点个赞安慰一下！下期咱们聊聊深拷贝和浅拷贝