受检异常必须显式处理，否则编译失败；即继承Exception（非RuntimeException子类）的异常需try-catch或throws声明，如IOException；运行时异常（如NullPointerException）继承RuntimeException，编译期不检查；Error（如OutOfMemoryError）不应捕获。
受检异常必须显式处理，否则编译失败
Java 编译器强制要求你对 Exception 及其子类（但不包括 RuntimeException）做处理：要么用 try-catch 捕获，要么在方法签名中用 throws 声明。这是编译期检查，不是运行时行为。
典型例子：IOException、SQLException、ClassNotFoundException。比如调用 FileInputStream 构造函数时抛出的 FileNotFoundException，不处理就过不了编译。
- 即使你确定该异常不会发生（比如读取 classpath 下的资源文件），也得写
try-catch或加throws - 过度使用受检异常会导致 API 设计僵硬，调用链层层
throws是常见反模式 - 自定义受检异常需继承
Exception，且不能是RuntimeException的子类
运行时异常继承 RuntimeException，编译器不管
RuntimeException 及其所有子类（如 NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException）属于运行时异常。它们在编译阶段完全不被检查，程序可以正常编译通过，只在运行时才可能抛出。
这类异常通常反映程序逻辑错误或非法输入，应该靠代码审查、单元测试和防御性编程来避免，而不是靠 try-catch 到处兜底。
立即学习“Java免费学习笔记（深入）”；
- 不要在方法签名里声明
throws NullPointerException—— 没意义，编译器也不认 - 自定义运行时异常应继承
RuntimeException，而非直接继承Exception - 捕获
RuntimeException本身通常是危险信号，容易掩盖真实 bug
Throwable 是根，Error 一般不该捕获
所有异常都继承自 Throwable。Error（如 OutOfMemoryError、StackOverflowError）和 Exception 是它的两个并列子类。Error 表示严重系统问题，JVM 都可能无法继续运行。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
除非你在写容器、框架或监控代理，否则不应该尝试捕获 Error：
- 捕获
OutOfMemoryError后几乎无法安全恢复，反而可能让状态更混乱 -
ThreadDeath是Error的子类，已被废弃，不要依赖 - 写日志或清理资源可以放在
finally或try-with-resources中，而不是靠 catch Error
如何快速判断一个异常是受检还是运行时？
看它的直接父类是不是 RuntimeException。不是？再往上查，只要最终继承自 Exception 且**没经过 RuntimeException**，就是受检异常。
IDE 里按住 Ctrl（Windows）或 Cmd（macOS）点进去看类定义最准。命令行下也可以用：
javap -s java.lang.NullPointerException
输出中若显示 Ljava/lang/RuntimeException; 就是运行时异常；若显示 Ljava/lang/Exception; 且没有 RuntimeException 在继承链上，就是受检异常。
别靠名字猜——UnsupportedOperationException 听着像“不支持功能”该报错，但它其实是 RuntimeException 子类，完全不用声明。
