受检异常必须显式处理，否则编译不通过；运行时异常继承自RuntimeException，编译器不检查；Error代表JVM严重问题，一般不捕获。
受检异常必须显式处理，否则编译不通过
Java 编译器强制要求你对 Exception 及其子类（但排除 RuntimeException）做出响应：要么用 try-catch 捕获，要么在方法签名中用 throws 声明。这是编译期检查，和运行行为无关。
常见受检异常包括：IOException、SQLException、ClassNotFoundException。它们代表外部可预期的失败场景，比如文件不存在、网络中断、数据库连接失败。
- 不写
try-catch也不加throws→ 编译报错：Unhandled exception type XXX - 即使你知道它“实际不会发生”，也得处理 —— 比如
new String(byteArr, "UTF-8")抛出UnsupportedEncodingException，但"UTF-8"是 JDK 强制支持的编码，此时仍需包裹或声明 - 过度使用受检异常会导致调用链上层层
throws，污染 API 设计；合理做法是封装后转为运行时异常（如 Spring 的DataAccessException）
运行时异常继承自 RuntimeException，编译器不管
RuntimeException 及其所有子类（如 NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException）属于运行时异常。它们代表程序逻辑错误，本应由开发者提前避免，而非靠调用方兜底。
这类异常发生时，JVM 直接中断当前执行流，向上抛出直到被捕获或终止线程。你完全可以选择不捕获 —— 大多数时候这是推荐做法。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 捕获
NullPointerException通常掩盖了空值来源问题，应优先修复判空逻辑 -
IllegalArgumentException常用于构造函数或 setter 中校验参数，抛出即表明调用方传入非法值，不该被静默吞掉 - 自定义运行时异常建议继承
RuntimeException，不要加throws声明，保持调用轻量
Throwable 是根，Error 一般不捕获
所有异常都继承自 Throwable，它有两个直接子类：Exception 和 Error。后者代表 JVM 层严重问题，比如 OutOfMemoryError、StackOverflowError、NoClassDefFoundError。
这些不是程序能“恢复”的状态，捕获它们往往无效，甚至干扰 JVM 的错误处理机制。
- 不要写
catch (Error e)或catch (Throwable t)来兜底 —— 除非你在写监控代理或容器框架 -
NoClassDefFoundError不等于ClassNotFoundException：前者是类已加载过、再次解析失败（如静态块抛异常），后者是首次加载就找不到字节码 - 某些框架（如 Spring）会把部分
Error包装成RuntimeException再抛出，便于统一处理，但这属于设计选择，不是语言规则
如何快速判断一个异常是受检还是运行时？
看它的直接父类是不是 RuntimeException 或 Error。如果是，就是运行时异常或错误；否则，只要它是 Exception 的子类，就是受检异常（Exception 本身也是受检的）。
IDE 里按住 Ctrl 点进去看继承链最准。别依赖名字：比如 NumberFormatException 听起来像 IO 错误，但它继承自 IllegalArgumentException，所以是运行时异常。
-
InterruptedException是受检异常，但常出现在循环中，需配合Thread.interrupted()清除中断状态，否则可能丢失信号 -
CloneNotSupportedException是受检异常，但Object.clone()已被标记为@Deprecated，现代代码更倾向用构造函数或 builder 复制对象 - 第三方库若抛出未声明的受检异常（比如某 SDK 方法文档说抛
Exception），实际可能是包装过的运行时异常，这时要以运行时方式对待
