1. 异常体系的地基从Throwable开始梳理很多人把Java异常学成了背面试题知道有checked异常和unchecked异常知道try-catch能捕获异常但一旦遇到实际项目里的诡异报错立刻抓瞎。原因很简单——你只记住了树的叶子没记住树根。本文这一讲就是把异常类这棵树的根和主干讲透然后再带你看看实际写代码时那些最容易踩的坑。1.1 Throwable、Error、Exception三者的真实关系Java里所有异常相关的类最终都追溯到一个类java.lang.Throwable。这个类本身实现了Serializable接口意味着异常对象是可以被序列化的——这在跨进程传递异常信息时很有用但平时我们基本意识不到这一点。Throwable下面直接分出两个分支Error和Exception。Error代表JVM层面发生的严重问题比如OutOfMemoryError内存耗尽、StackOverflowError栈溢出、NoClassDefFoundError类定义找不到。这类问题的典型特征是程序本身无法处理也不应该尝试去捕获处理。你想内存都耗尽了你catch住这个Error又能怎么样呢连创建新对象都做不到了强行catch反而可能引发二次故障。Exception代表程序运行期间可以恢复、可以处理的问题。比如文件找不到、网络超时、参数格式错误。这里又分成两类后面专门讲。这里有个很重要的认知捕获异常不等于吞掉故障。很多程序员看到Exception就习惯性加个try-catch这是一种条件反射式的防御但往往是无效防御。真正专业的做法是先判断这个异常我catch了有没有意义。如果是Error分支除非确实需要特殊场景比如某些服务器框架需要在OOM前做资源清理否则一律不做捕获处理。1.2 异常信息的传递链条从哪来回哪去初学者经常搞不懂异常到底是怎么冒出来的。看一段最简单的代码public class Demo { public static void main(String[] args) { int result divide(10, 0); System.out.println(result); } public static int divide(int a, int b) { return a / b; } }运行后控制台会打印一个堆栈轨迹Stack Trace第一行通常是Exception in thread main java.lang.ArithmeticException: / by zero然后是at开头的调用栈信息。这个堆栈轨迹就是异常信息传递的具体体现divide方法里的算术运算触发了ArithmeticException当前方法没有捕获它异常对象就沿着调用栈向上抛先到main方法main也没捕获最终到达JVMJVM把异常信息连同完整的调用栈打印到控制台然后终止当前线程。理解这个传递机制对后面理解什么时候该捕获、什么时候该抛出非常关键。异常的本质是控制流的转移当异常发生时当前代码块的正常执行顺序被打断转而寻找匹配的catch处理器。找不到就一直往上走直到某处能处理或者直接暴露给JVM。2. checked异常与unchecked异常编译器凭什么多管闲事这是Java异常体系设计上最核心的划分也是面试里反复问的东西。不过面试题只会问区别是什么实际开发中真正的难点是哪些场景必须声明throws哪些不用以及背后的设计哲学是什么。2.1 RuntimeException及其子类程序员自己的逻辑问题RuntimeException运行时异常及其所有子类统称为unchecked异常。编译器不会强制你捕获或者声明抛出。常见的就有NullPointerException空指针、ArrayIndexOutOfBoundsException数组越界、ClassCastException类型转换错误、ArithmeticException算术异常、IllegalArgumentException非法参数、IndexOutOfBoundsException下标越界等等。这一类异常的特征是它们是可以通过代码逻辑检查提前规避的。比如数组越界你在访问数组前先判断一下index 0 index array.length就能完全避免。比如空指针先判断对象是否为null再调用方法就不会触发。所以Java设计者把这类异常定位为程序员写代码时的逻辑错误既然是逻辑错误就不该让编译器每个方法都强制声明否则代码里会满屏都是throws NullPointerException毫无意义。靠编译器的强制约束解决不了逻辑缺陷——这是关键设计思想。2.2 受检异常checked exception来自外部环境的合理风险和RuntimeException相对的是直接继承Exception类但不继承RuntimeException的那一大票异常比如IOException、SQLException、FileNotFoundException、ClassNotFoundException等。它们被称为checked异常受检异常。编译器强制要求如果某段代码可能抛出这类异常那么要么用try-catch把它捕获处理掉要么在方法声明处加上throws把它抛给调用方。两者必须选一个否则编译不通过。为什么要这么强势因为这类异常通常代表外部环境不可控因素导致的错误文件可能不存在、网络可能断开、数据库可能连不上。这些都不是你改改代码逻辑就能100%规避的。设计者的意图是通过编译器强制让你在编译期就意识到这段操作可能失败并逼迫你在代码里显式处理这种失败路径。举个实际例子public static void readConfig() throws IOException { FileInputStream fis new FileInputStream(config.properties); // ... }这里FileInputStream构造函数会抛出FileNotFoundExceptionIOException的子类所以要么在方法上声明throws IOException要么try-catch。不处理编译直接报错。2.3 区别背后的实际意义代码风格的分水岭理论上讲得很清楚了但实际开发中的较真点在哪里第一分层架构中的异常传播。在Service层调用DAO层时DAO层抛出的SQLException是checked异常Service层通常不该直接向上抛一个底层异常给Controller层因为Controller层的调用者根本不关心数据库连接池满了还是SQL写错了。主流做法是包装成自定义的业务异常unchecked类型在Service层把底层异常翻译成上层的语义化异常。这种做法后面讲自定义异常时细说。第二框架对两种异常的处理方式完全不一样。以Spring为例Transactional事务方法内部抛出checked异常时默认事务不会回滚认