java编译器对ioexception等受检异常强制检查，未try-catch或throws则编译失败；而nullpointerexception等运行时异常编译期不检查，仅在运行时抛出。
编译器会直接报错：没处理受检异常就过不了编译
Java 编译器对 IOException、SQLException、ClassNotFoundException 这类受检异常是“较真”的——只要方法体里调用了可能抛出它们的 API，又没用 try-catch 包住，也没在方法签名加 throws，javac 就会拒绝编译，报类似这样的错误：
error: unreported exception IOException; must be caught or declared to be thrown
这不是警告，是硬性拦截。你必须二选一：try-catch 吞掉或处理它，或者把责任推给调用方，写成 public void readFile() throws IOException。
常见误操作：
- 复制一段带
FileInputStream的代码，直接粘贴进新方法，忘了补throws IOException，结果编译失败，一脸懵 - 在 lambda 表达式里读文件（比如
list.forEach(f -> Files.readAllBytes(Paths.get(f)))），但Files.readAllBytes抛的是受检异常，lambda 无法声明throws，直接编译不过
非受检异常可以完全不管：编译器连眼皮都不抬
NullPointerException、IllegalArgumentException、ArrayIndexOutOfBoundsException 这些非受检异常，编译器压根不检查。哪怕你明知道某行会空指针，写 obj.toString() 而 obj 是 null，javac 也照常通过。
但这不等于它们不存在——运行时一触发，线程就崩，堆栈打出来，程序挂掉。所以“可以不管” ≠ “应该不管”。实际开发中，该加判空、该校验参数的地方，还是得自己写。
容易被忽略的点：
- 很多人以为
RuntimeException子类只是“测试时才出”，其实生产环境高频出现，比如 JSON 解析返回null后直接调用.size() - 把受检异常包装成非受检异常再抛出（如
throw new RuntimeException(e)）能绕过编译检查，但等于主动放弃异常分类语义，后续排查成本陡增
怎么一眼判断一个异常是不是受检的
看继承链最直接：不是 RuntimeException 或其子类，也不是 Error 或其子类，但属于 Exception，那就是受检异常。
实战小技巧：
- IDE 里按住 Ctrl（或 Cmd）点异常类名，跳进去看
extends那行；如果最终指向class MyException extends Exception，且没经过RuntimeException，就是受检的 - 查 Javadoc：官方文档里明确标注 “Checked exception” 的，就是编译器强制派
- 记几个典型：所有以
Exception结尾但不含Runtime的（如ParseException、InterruptedException），基本都是受检的；而所有以Exception结尾且含Runtime的（如RuntimeException、IllegalArgumentException），都是非受检的
为什么设计成两套规则：别把逻辑错误和外部故障混为一谈
受检异常对应的是“程序之外的事”：磁盘坏了、网络断了、数据库连不上、配置文件丢了……这些你写代码时无法避免，但可以预设恢复路径（重试、降级、提示用户）。编译器强制你面对，是提醒“这事可能发生，你得想好怎么办”。
非受检异常对应的是“程序之内的错”：传了个 null 还敢调方法、数组长度都没校验就硬取下标、类型强转前不 instanceof……这些本该在编码阶段消灭，靠运行时暴露只是兜底。
真正容易踩坑的是中间地带：比如自定义异常，继承 Exception 却抛在纯内存计算逻辑里，导致调用方被迫处理一个本不该发生的“外部问题”；或者继承 RuntimeException 却用来包装 IO 失败，让下游完全意识不到这个调用可能因磁盘故障而失败。
