编译器是否拦截是唯一判断标准：受检异常不处理则编译失败，运行时异常编译通过、运行才抛；关键看继承链是否经过RuntimeException，而非类名或发生时机。
编译器是否拦你，是唯一判断标准：受检异常不处理就过不了编译，运行时异常爱抛不抛，编译器不管。
看编译器报错就能立刻分辨
写一行 new FileInputStream("missing.txt")，不加 try-catch 也不加 throws IOException，javac 直接报错：Unhandled exception type FileNotFoundException —— 这就是受检异常的强制性体现。而写 list.get(100)，哪怕 list 是空的，编译照样通过，运行才崩，因为 IndexOutOfBoundsException 是 RuntimeException 的子类。
关键不是“它会不会发生”，而是“编译器认不认识它该不该管”：
- 继承链最终落在
Exception上，但**没经过RuntimeException** → 受检异常 - 继承链里只要出现过
RuntimeException（哪怕只隔一层）→ 运行时异常 -
Error及其子类（如OutOfMemoryError）既不是受检也不是运行时异常，编译器同样不检查，但你不该捕获它
为什么 InterruptedException 是个典型陷阱
InterruptedException 名字里没 “Runtime”，但它在 java.lang 包里，父类是 Exception，且**不是 RuntimeException 的后代** → 它是受检异常。很多人误以为“线程中断算运行时行为”，结果漏写处理，导致中断信号被静默吞掉，线程无法响应停止指令。
立即学习“Java免费学习笔记（深入）”；
正确做法不是忽略，而是至少做两件事之一：
- 在方法签名中声明
throws InterruptedException，把责任往上传 - 捕获后调用
Thread.currentThread().interrupt()恢复中断状态，而不是只打日志或什么都不做
漏掉第二步，等于把中断标记擦掉了，上层代码再也感知不到这个线程该停了。
自定义异常时怎么选父类
选 Exception 还是 RuntimeException，取决于你希望调用方“必须面对”还是“可以忽略但不应掩盖”：
- 业务上可预期、需主动干预的失败（如余额不足、权限校验不通过）→ 继承
Exception，强制调用方决策：是重试、降级，还是向上抛？ - 程序明显写错了才触发的失败（如传入
nullID 调用 DAO、状态枚举值非法）→ 继承RuntimeException，靠测试和代码审查提前暴露，而不是让每个调用点都写try-catch
注意：不要为了“省事”把所有异常都做成运行时异常；也不要为了“严谨”把所有异常都做成受检异常——前者让错误沉默，后者让 API 被 throws 污染得没法用。
catch (Exception e) 是危险操作
这种写法表面兜底，实际会捕获到本不该你处理的东西：
- 可能拦下
OutOfMemoryError，导致 JVM 已经快崩了你还试图继续执行逻辑 - 可能吞掉
InterruptedException，中断语义彻底丢失 - 掩盖真实异常类型，调试时只剩一个泛泛的
e.printStackTrace()，看不出是空指针还是文件找不到
真正需要的，是按具体异常类型分层处理：比如 IOException 做重试，IllegalArgumentException 直接返回 400，SQLException 转成统一的数据访问异常再抛出。
最易被忽略的一点：受检异常的强制性只存在于编译期，JVM 运行时对两类异常的抛出、栈展开、性能开销完全一致。所谓“性能差”，纯属误解；所谓“必须处理”，也只是编译器在你写完代码那一刻拉住你问一句：“这个外部不确定性，你想怎么回应？”——答不上来，它就不让你交卷。
