检查型异常必须显式处理，否则编译失败；Java强制要求对Exception及其子类（除RuntimeException外）用try-catch捕获或throws声明，如IOException、SQLException；而RuntimeException及其子类（如NullPointerException）属运行时异常，无需强制处理。
检查型异常必须显式处理，否则编译失败
Java 编译器强制要求你对 Exception 及其子类（但不包括 RuntimeException）做处理。这意味着：调用可能抛出检查型异常的方法时，要么用 try-catch 捕获，要么在方法签名中用 throws 声明。不这么做，javac 直接报错，比如：
error: unreported exception IOException; must be caught or declared to be thrown
new FileInputStream("file.txt");
常见检查型异常包括：IOException、SQLException、ClassNotFoundException。它们代表外部可预期但不可控的问题，比如文件不存在、网络中断、数据库连接失败。
注意：Exception 本身是检查型的，但它的子类 RuntimeException 是特例——所有继承自 RuntimeException 的异常都自动变成非检查型。
运行时异常可以不捕获，编译器不管
RuntimeException 及其子类（如 NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException）属于运行时异常。它们通常反映程序逻辑缺陷，比如空指针、数组越界、传入非法参数。
立即学习“Java免费学习笔记（深入）”；
这类异常不要求你在代码中显式处理，编译器完全放行。但一旦发生，JVM 会沿调用栈向上抛，直到被捕获或导致线程终止。
容易混淆的点：
-
Throwable是根类，Error和Exception都继承它；Error（如OutOfMemoryError）也不检查，但一般不该捕获 -
RuntimeException是Exception的子类，但它被 JVM “豁免”了检查义务 - 自己定义异常时：继承
Exception→ 检查型；继承RuntimeException→ 运行时异常
如何快速判断某个异常是不是检查型
最可靠的方式是看它的直接父类：
- 如果父类是
RuntimeException或其任意子类 → 运行时异常 - 如果父类是
Exception且不是RuntimeException的后代 → 检查型异常 - 如果父类是
Error→ 不检查，也不该捕获（除非极特殊场景）
例如：ParseException 继承自 Exception，没继承 RuntimeException，所以是检查型；而 ConcurrentModificationException 继承自 RuntimeException，所以是运行时异常。
IDE 里把鼠标悬停在异常类名上，能立刻看到继承链；命令行可用 javap -s java.time.format.DateTimeParseException 查签名确认。
设计自定义异常时的关键取舍
要不要让自定义异常成为检查型，取决于它是否属于“调用方理应预见并恢复”的问题：
- 选
extends Exception：比如InsufficientBalanceException，业务上明确需要调用方做余额不足的兜底处理 - 选
extends RuntimeException：比如InvalidOrderStateException，本质是状态机逻辑错误，应该修复代码而非现场捕获
过度使用检查型异常会导致 API 被 throws 污染，调用方被迫写大量空 catch 或无意义的 throws 向上传递。反过来，把本该检查的异常设为运行时，会让问题潜伏到线上才暴露。
真正难的不是分类，而是判断这个异常发生时，谁有能力、有责任、有上下文去处理它——这决定了它是检查型还是运行时异常。
