企业官网建设流程全解析

1. 从一个让新手抓狂的编译报错说起

如果你写过Java，大概率见过这样的场景：方法签名里明明写了throws，调用的时候还是被编译器追着骂；或者代码里写了throw new RuntimeException()，反而一路畅通无阻。更让人迷惑的是，有些方法声明了throws IOException，调用方不处理也能编译通过——前提是那个异常是运行时异常。

这些现象背后，其实都指向同一个问题：throw和throws到底有什么区别，各自在什么场景下用，编译器又是怎么判断该不该报错的。

这两个词长得像、发音像、拼写只差一个字母，但它们在Java异常处理体系里扮演的角色完全不同。throw是一个动作，是真正把异常对象"扔出去"的那一下；throws是一份声明，是提前告诉调用方"我这个方法可能会扔出这些东西，你看着办"。一个是执行层面的操作，一个是契约层面的约定。

很多人学Java的时候把这两个词混着记，结果一到实际项目里就出问题：要么该声明的不声明，要么声明了一堆用不上的异常，要么在catch块里把异常吞掉导致线上问题排查无从下手。这篇文章就从实际开发的角度，把这两个词的边界、用法、常见坑和排查思路一次讲清楚。不管你是刚学Java的新手，还是写了几年代码但异常处理一直靠直觉的老手，应该都能从中找到一些之前没注意到的细节。

2. throw与throws的本质差异：动作与契约的分野

2.1 throw是语句，throws是声明

先从最基础的语法层面把两者拆开。

throw是一个语句，它出现在方法体内部，执行到这一行的时候，程序会立即中断当前执行路径，把后面跟着的异常对象抛给上层调用栈。它的语法形式是：

throw new SomeException("异常信息");

注意，throw后面必须是一个异常对象实例，不能是异常类名。也就是说，你得new出来一个，或者拿到一个已经存在的异常引用。这一行执行之后，当前方法中throw之后的代码不会再执行，控制权直接交给调用方或者JVM的异常处理机制。

throws是一个声明，它出现在方法签名的末尾，用来告诉编译器和方法调用者：这个方法在执行过程中可能会抛出哪些受检异常。它的语法形式是：

public void readFile(String path) throws IOException, FileNotFoundException { // 方法体 }

throws后面跟的是异常类名，可以跟多个，用逗号分隔。它本身不产生任何运行时行为，纯粹是一份"合同"——我提前告诉你我可能出什么问题，你调用我的时候得做好准备。

用一个生活化的类比：throws就像餐厅菜单上写的"本店菜品可能含有坚果"，是提前告知；throw就像厨师发现菜里有问题，直接把盘子端回厨房，是实际发生的动作。菜单上写了不代表一定会发生，但一旦发生，你得有应对方案。

2.2 编译器眼中的两者：完全不同的检查逻辑

编译器对throw和throws的处理逻辑是分开的，理解这一点能解释很多"为什么这里报错那里不报错"的困惑。

对于throw语句，编译器会检查两件事：第一，你扔出去的是不是Throwable的子类实例；第二，如果你扔的是受检异常（Checked Exception），那么当前方法要么用try-catch把它捕获处理掉，要么在方法签名上用throws声明出去。如果两者都没做，编译直接失败。

对于throws声明，编译器检查的是：你声明的异常类型必须是Throwable的子类；子类方法重写父类方法时，throws声明的异常不能比父类方法更宽泛（可以更少或更具体）；接口实现类同理。

这里有一个很多人踩过的坑：throws声明了某个异常，不代表方法里一定会throw它。你完全可以写一个方法声明throws IOException，但方法体里一行throw都没有。编译器不会报错，因为throws是"可能抛出"，不是"一定抛出"。反过来，方法体里throw了一个受检异常，但签名里没声明、也没catch，编译器一定报错。

2.3 受检与非受检：决定throws是否强制的那条线

Java的异常体系里，Throwable下面分两支：Error和Exception。Exception下面又分RuntimeException和其他受检异常。这条分界线直接决定了throws是不是强制的。

这张表解释了一个常见困惑：为什么throw new RuntimeException()不需要在方法签名里写throws RuntimeException，而throw new IOException()就必须写或者catch。因为运行时异常被认为是"程序逻辑问题"，编译器不强制你处理；受检异常被认为是"外部环境问题"，编译器强制你表态。

注意：虽然运行时异常不强制声明，但在实际项目中，如果你自定义了一个运行时异常并打算让调用方感知，在方法签名里显式写上throws也是一种好习惯，相当于文档化你的意图。

3. 方法签名里的throws：什么时候必须写，什么时候可以不写

3.1 受检异常的三条出路

当一个方法内部可能产生受检异常时，你有且只有三条路可以走：

第一条路是就地捕获。用try-catch把可能出问题的代码包起来，在catch块里处理掉。处理方式可以是记录日志、降级返回默认值、转换成运行时异常再抛出等。这条路走完之后，方法签名上不需要写throws。

第二条路是向上声明。在方法签名上用throws把异常类型列出来，让调用方去处理。这条路适合当前方法确实没有能力处理这个异常的场景，比如一个底层的文件读取工具方法，它不知道调用方想怎么处理文件不存在的情况，那就声明出去。

第三条路是转换后抛出。在catch块里捕获受检异常，包装成一个运行时异常或者自定义的业务异常再抛出。这样方法签名上也不需要写throws，但调用方如果想知道底层出了什么问题，可以通过异常链（cause）追溯。

三条路没有绝对的好坏，关键看当前方法在架构中的位置和职责。底层工具类倾向于声明，业务服务层倾向于转换，最外层的控制器倾向于捕获并返回友好提示。

3.2 重写方法时throws的收缩规则

子类重写父类方法时，throws声明有一个明确的约束：不能比父类方法声明的异常更宽泛。具体来说：

• 可以完全不声明任何异常（收缩到零）
• 可以声明父类方法声明异常的子类（更具体）
• 可以声明父类方法声明异常的部分异常（更少）
• 不能声明父类方法没有声明的新的受检异常
• 不能声明父类方法声明异常的父类（更宽泛）

这个规则的原因在于多态：如果父类引用指向子类对象，调用方按照父类的throws声明来写catch块，子类如果抛出了父类没声明的受检异常，调用方的catch就接不住，程序会出问题。编译器从源头上堵住了这个漏洞。

class Parent { public void doSomething() throws IOException {} } class Child extends Parent { // 合法：不声明任何异常 public void doSomething() {} // 合法：声明更具体的异常 // public void doSomething() throws FileNotFoundException {} // 非法：声明更宽泛的异常 // public void doSomething() throws Exception {} // 非法：声明父类没有的受检异常 // public void doSomething() throws SQLException {} }

运行时异常不受这个规则限制，子类方法可以随意抛出运行时异常，编译器不管。

3.3 接口实现与throws的灵活空间

接口方法的throws声明和类继承的规则类似，但有一个细微差别：接口方法如果声明了throws，实现类可以选择不声明，也可以声明更具体的。如果接口方法没声明任何受检异常，实现类也不能声明新的受检异常。

这个特性在设计接口的时候很有用。你可以定义一个接口方法不声明任何受检异常，强制所有实现类在内部把受检异常处理掉，对外只暴露运行时异常。这样调用方就不需要写一堆try-catch，代码会更干净。代价是实现类的编写者要承担更多的异常处理责任。

4. throw语句的实战细节：从异常对象构造到栈轨迹

4.1 异常对象的构造与信息量

throw后面跟的异常对象，构造的时候有几个信息值得认真填：

第一个是message。new IOException("文件读取失败: " + path)比new IOException()在排查问题时有用得多。message应该包含足够的上下文：操作是什么、操作对象是什么、关键参数是什么。但注意不要把敏感信息写进去，比如密码、密钥、完整的用户数据。

第二个是cause。当你捕获一个异常然后抛出另一个异常时，一定要把原始异常作为cause传进去：throw new ServiceException("处理订单失败", e)。这样异常栈里会保留完整的调用链路，排查的时候能看到"根因是什么"。如果只写throw new ServiceException("处理订单失败")，原始异常的信息就丢了，线上排查会非常痛苦。

第三个是自定义异常类。如果项目里频繁出现某一类业务异常，定义一个继承自RuntimeException的自定义异常类比到处throw new RuntimeException("xxx")要好。好处是调用方可以精确catch，也可以在里面封装一些业务字段，比如错误码、用户提示语等。

4.2 throw之后的代码为什么不能写

throw语句执行后，当前方法的执行路径立即中断，后面的代码不会被执行。编译器知道这一点，所以如果你在throw后面直接写代码，编译器会报"unreachable statement"错误。

public void check(int value) { if (value < 0) { throw new IllegalArgumentException("值不能为负"); // System.out.println("这行永远不会执行"); // 编译错误 } System.out.println("值合法"); }

这个规则在if块里有个细节：如果throw在if块里，if块外面的代码是可达的，因为if条件可能不成立。编译器只对无条件执行路径上的不可达代码报错。

实际写代码的时候，throw经常和return配合使用，形成"要么返回正常结果，要么抛出异常"的清晰逻辑。这种写法比返回null或者特殊值要安全得多，调用方不容易忘记检查。

4.3 在catch块里throw的注意事项

在catch块里再次throw是常见操作，但有几个坑要注意。

第一个坑是吞掉原始异常。前面提过，转换异常时一定要传cause。还有一种更隐蔽的吞异常方式：catch块里只打了日志，没有重新抛出，也没有做任何有意义的处理。这种代码在review的时候很容易被放过，但线上出问题的时候，日志可能因为级别配置或者滚动策略丢失，导致问题无法追溯。

第二个坑是在finally块里throw。如果try块里抛了异常，finally块里又抛了一个，那么try块的异常会被覆盖掉，你只能看到finally块的异常。这是一个非常隐蔽的bug来源。正确的做法是finally块里只做资源释放，不要抛异常；如果释放资源时确实出错了，也要谨慎处理，避免覆盖主异常。

第三个坑是catch了过于宽泛的异常。catch (Exception e)会捕获所有异常，包括你不想捕获的运行时异常。这会导致一些本该暴露出来的编程错误被掩盖。比较好的实践是：能精确catch就精确catch，确实需要兜底的时候再catch宽泛异常，并且在catch块里做好日志记录和异常分类。

5. 异常处理策略：从声明到捕获的完整链路设计

5.1 分层架构中的异常处理分工

在一个典型的分层架构里，异常处理应该是有分工的，而不是每层都随便catch一下。

数据访问层通常直接和外部资源打交道，抛出的多是受检异常（比如数据库连接失败、文件读写失败）。这一层可以选择声明这些异常，让上层去决定怎么处理；也可以转换成自定义的数据访问异常再抛出，屏蔽底层细节。

业务服务层是异常处理的核心地带。它需要决定哪些异常是可以恢复的（比如库存不足可以提示用户），哪些是系统故障（比如数据库宕机需要告警）。可恢复的异常转换成业务异常抛出，系统故障的异常记录日志后继续向上抛。

控制层/接口层是最外层，负责把异常转换成用户能理解的响应。这一层通常有一个全局异常处理器，根据异常类型返回不同的错误码和提示信息。受检异常在这一层基本都会被catch掉，不会再往上抛。

这个分工的核心原则是：谁有能力处理，谁就处理；谁处理不了，谁就声明或转换。最怕的是每一层都catch一下、打条日志、然后什么都不做，异常就像进了黑洞。

5.2 受检异常与运行时异常的选用判断

什么时候该用受检异常，什么时候该用运行时异常，这是Java异常处理里争论最多的话题之一。我自己的判断标准是这样的：

如果这个异常是调用方可以合理恢复的，用受检异常。比如"文件不存在"，调用方可以提示用户重新选择文件，这是一个合理的恢复路径。受检异常强制调用方考虑这个场景，不会漏掉。

如果这个异常是调用方无法处理的编程错误或系统故障，用运行时异常。比如"参数为null"，这是调用方的代码bug，强制它catch也没有意义，不如让它快速失败，在开发阶段就暴露出来。

如果这个异常是业务规则违反，比如"余额不足"、"库存不够"，我倾向于用自定义的运行时异常。因为业务异常通常需要在全局异常处理器里统一转换成用户提示，用运行时异常可以避免每层都声明throws，代码更干净。

5.3 try-catch的粒度控制

try-catch的粒度是一个容易被忽视但影响很大的细节。

粒度过大：把一大段代码包在一个try块里，catch了异常之后你根本不知道是哪一行出的问题。而且try块里的代码越多，出现预期外异常的概率越大，catch块可能捕获到你没想处理的异常。

粒度过小：每一行都包一个try-catch，代码会变得非常臃肿，可读性极差。而且很多异常处理逻辑是重复的，应该抽取出来。

比较合理的做法是：按照业务操作的边界来划分try块。一个完整的业务操作（比如"创建订单"）放在一个try块里，这个操作内部的多个步骤如果抛出异常，统一在catch块里处理。如果某个步骤有特殊的恢复逻辑，再单独包一层。

还有一个细节：try块里尽量不要写无关代码。比如你只想捕获Integer.parseInt的异常，就不要把后面的业务逻辑也放进try块。缩小try块的范围，能让catch块更精确地对应到具体的异常来源。

6. 那些年我们踩过的throw与throws的坑

6.1 声明了throws但调用方不处理却能编译通过

这个现象让很多人困惑：方法A声明了throws IOException，方法B调用A，但B既没有try-catch也没有声明throws，为什么编译器不报错？

答案通常是：B方法本身也声明了throws，或者B方法是一个lambda表达式/匿名内部类，异常被包装了。还有一种可能是你看错了，B方法确实声明了throws，只是声明的位置在你看不到的地方（比如接口定义里）。

如果确认B方法既没catch也没声明，那唯一的解释是：A方法声明的异常实际上是运行时异常，或者A方法根本没有真正抛出受检异常（声明了但没throw，编译器不强制调用方处理）。

提示：throws声明了受检异常，但方法体里没有任何路径能抛出这个异常时，编译器不会报错，但一些静态分析工具会给出警告。这种"过度声明"会让调用方写很多无用的catch块，建议定期清理。

6.2 在lambda表达式里throw受检异常的麻烦

Java 8引入lambda之后，一个常见的痛点是：lambda表达式里不能直接throw受检异常，因为函数式接口的方法签名通常没有声明throws。

List<String> paths = Arrays.asList("a.txt", "b.txt"); paths.forEach(path -> { // 编译错误：未处理的IOException // Files.readAllLines(Paths.get(path)); });

解决办法有几种：一是在lambda内部try-catch，把受检异常转换成运行时异常；二是自定义一个允许抛出受检异常的函数式接口；三是把可能出异常的代码抽成一个单独的方法，在方法签名上声明throws，然后在lambda里调用这个方法（但这样lambda里还是要处理）。

实际项目里，第一种方式最常用，虽然有点丑，但胜在简单直接。第二种方式更优雅，但需要额外定义接口，适合在框架层面使用。

6.3 异常链断裂导致排查困难

前面提过cause的重要性，这里再强调一个实际场景。

假设你有一个方法，内部调用了三个外部服务，每个服务都可能抛出不同的异常。如果你在每个catch块里都只写throw new ServiceException("调用失败")，那么线上出问题的时候，你只能看到"调用失败"，不知道是哪个服务、什么原因失败。

正确的做法是：

try { callServiceA(); } catch (ServiceAException e) { throw new ServiceException("调用服务A失败", e); }

这样异常栈里会保留ServiceAException的完整信息，包括它的message和它自己的cause。排查的时候从最底层的cause开始看，能快速定位到根因。

还有一个细节：不要用e.getMessage()拼接新异常的信息然后丢掉e。e.getMessage()可能为null，也可能不包含堆栈信息。把e作为cause传进去，比拼接字符串要可靠得多。

6.4 finally块里的return会吞掉异常

这是一个经典坑，但每年还是有人踩。

public int test() { try { throw new RuntimeException("异常"); } finally { return 1; // 异常被吞掉，方法返回1 } }

finally块里的return会覆盖try块里抛出的异常，方法正常返回1，调用方完全感知不到异常。同样的，finally块里的throw也会覆盖try块的异常。

这个坑的隐蔽性在于：代码看起来很正常，review的时候如果不仔细看finally块，很容易放过。避免的方法很简单：finally块里只做资源释放，不要写return、throw、break、continue这些会改变控制流的语句。

7. 从字节码和JVM角度看异常处理

7.1 异常表：JVM如何知道该跳到哪里

Java源代码里的try-catch，编译成字节码之后会变成一张异常表（Exception Table）。这张表记录了：从哪条指令到哪条指令之间的代码（try的范围）、如果出现哪个异常类型、跳转到哪条指令（catch块的起始位置）。

当JVM执行过程中抛出异常时，它会沿着当前方法的异常表查找匹配的条目。如果找到匹配的，就跳转到对应的catch块执行；如果没找到，就弹出当前栈帧，把异常抛给调用方，继续在调用方的异常表里查找。这个过程一直持续到找到匹配的catch，或者到达栈底（此时线程终止，打印异常栈）。

throws声明在字节码层面体现为方法的Exceptions属性，它只是一个元数据，不影响JVM的异常查找逻辑。JVM的异常查找只看异常表，不看throws声明。throws主要是给编译器看的，用来做编译期的检查。

7.2 异常的性能开销在哪里

"异常很慢"是一个流传很广的说法，但具体慢在哪里，很多人说不清楚。

异常的性能开销主要在两个地方：构造异常对象和填充栈轨迹。new Exception()的时候，JVM会调用fillInStackTrace()，遍历当前线程的整个调用栈，把每一层的类名、方法名、行号等信息记录下来。这个操作在调用栈很深的时候开销很大。

如果异常被频繁抛出（比如在一个循环里），这个开销会累积。优化的思路有几种：一是避免用异常做流程控制，能用返回值判断的就不要抛异常；二是如果确实需要频繁抛出，可以重写fillInStackTrace()方法让它什么都不做（但这样会丢失栈信息，只适合那些不需要栈信息的场景）；三是用单例异常对象，避免重复构造（但同样有栈信息的问题）。

不过话说回来，大多数业务系统里异常并不是性能瓶颈，真正需要关注异常性能的是那些高频调用的底层框架。普通业务代码里，异常的可读性和可维护性比微秒级的性能差异重要得多。

7.3 受检异常在字节码里的体现

受检异常在字节码层面没有特殊的标记，它和运行时异常在JVM看来是一样的。受检和非受检的区别完全是编译器层面的约定。编译器在编译Java源码时，会检查受检异常是否被处理或声明，但编译成class文件之后，这个信息就只剩下Exceptions属性里的一个列表，JVM不会强制检查。

这也解释了为什么通过反射调用方法时，受检异常可以被"绕过"——反射API把所有异常都包装成InvocationTargetException，编译器无法做检查。调用方需要自己解开这个包装，拿到原始异常。

8. 一套可落地的异常处理规范

8.1 自定义异常体系的设计

在一个中型以上的项目里，建议设计一套自定义异常体系，而不是到处用JDK自带的异常。一个常见的分层设计是：

• 基础异常类：继承RuntimeException，包含错误码、用户提示语、HTTP状态码等字段。
• 业务异常类：继承基础异常类，用于业务规则违反的场景。
• 系统异常类：继承基础异常类，用于系统故障的场景。
• 第三方异常类：继承基础异常类，用于调用外部服务失败时包装原始异常。

这套体系的好处是：全局异常处理器可以根据异常类型做不同的处理（业务异常返回用户提示，系统异常记录日志并告警），调用方也可以精确catch自己关心的异常。

8.2 日志记录的正确姿势

异常日志记录有几个原则：

不要重复记录。如果异常在底层已经记录了日志，上层就不要再记录一遍，否则日志里会出现大量重复的堆栈信息。通常的做法是：在最外层（全局异常处理器）统一记录，中间层只做异常转换，不记录日志。

记录完整的堆栈。用log.error("消息", e)而不是log.error("消息" + e.getMessage())。前者会打印完整的堆栈轨迹，后者只有一行消息，排查的时候信息量差很多。

区分日志级别。业务异常（用户输入错误、业务规则违反）用WARN级别，系统异常（数据库连接失败、外部服务超时）用ERROR级别。这样日志监控系统可以根据级别做不同的告警策略。

8.3 全局异常处理器的实现要点

全局异常处理器（通常用@ControllerAdvice或类似机制实现）是异常处理的最后一道防线。它的核心逻辑是：

1. 根据异常类型判断是业务异常还是系统异常。
2. 业务异常返回用户友好的提示信息，HTTP状态码通常是200或400。
3. 系统异常记录ERROR日志，返回通用的错误提示（不要暴露内部细节），HTTP状态码通常是500。
4. 对于未知异常，统一兜底处理，避免异常信息直接暴露给用户。

有一个细节容易被忽略：全局异常处理器本身也可能抛异常。比如在构造错误响应的时候出了NullPointerException，这时候需要有兜底逻辑，返回一个最简的错误响应，而不是让异常继续往上抛导致容器返回默认的错误页面。

8.4 单元测试里如何验证异常

写单元测试的时候，验证异常行为是一个常见需求。JUnit提供了几种方式：

// 方式一：assertThrows（JUnit 5推荐） @Test void testThrow() { IllegalArgumentException exception = assertThrows( IllegalArgumentException.class, () -> validator.check(-1) ); assertEquals("值不能为负", exception.getMessage()); } // 方式二：try-catch + fail @Test void testThrowOldStyle() { try { validator.check(-1); fail("应该抛出异常"); } catch (IllegalArgumentException e) { assertEquals("值不能为负", e.getMessage()); } }

assertThrows的好处是能拿到异常对象，可以进一步断言message、cause等信息。而且如果方法没有抛出异常，测试会自动失败，不需要手动写fail。

对于受检异常，assertThrows同样适用，因为lambda表达式里可以抛出受检异常（Executable接口的execute方法声明了throws Throwable）。

9. 几个容易混淆的边界场景

9.1 throw在构造方法里的使用

构造方法里也可以throw异常，而且这是一个常见的参数校验手段。

public User(String name) { if (name == null || name.isEmpty()) { throw new IllegalArgumentException("name不能为空"); } this.name = name; }

构造方法里throw异常会导致对象创建失败，调用方拿不到对象引用。这个特性可以用来做"要么创建成功，要么抛出异常"的强约束，比创建一个半成品对象然后让调用方去检查要安全。

但要注意：如果构造方法声明了受检异常，子类构造方法也必须声明同样的异常或者更具体的异常。而且匿名内部类的构造方法不能声明受检异常，这是一个限制。

9.2 静态初始化块里的异常

静态初始化块（static {}）里如果抛出异常，会导致ExceptionInInitializerError。这个错误比较特殊，它包装了原始异常，可以通过getCause()或者getException()拿到。

static { if (someCondition) { throw new RuntimeException("初始化失败"); } }

静态初始化块里抛异常的场景不多，但一旦出现，排查起来比较麻烦，因为错误信息可能不够直观。建议在静态初始化块里做好异常处理，把原始异常的信息保留下来。

9.3 try-with-resources与异常抑制

Java 7引入的try-with-resources是资源管理的推荐方式，它和异常处理有一个交互细节值得注意。

try (FileInputStream fis = new FileInputStream("a.txt")) { // 使用fis } catch (IOException e) { // 处理异常 }

如果try块里抛了异常，同时close()方法也抛了异常，那么close()的异常会被抑制（suppressed），原始异常是主异常。被抑制的异常可以通过Throwable.getSuppressed()获取。

这个机制保证了主异常不会被资源关闭的异常覆盖，是一个很贴心的设计。但如果你在catch块里只打印了e.getMessage()，被抑制的异常信息就丢了。建议用log.error("消息", e)，日志框架会自动打印被抑制的异常。

9.4 多catch块的顺序问题

try { // ... } catch (FileNotFoundException e) { // ... } catch (IOException e) { // ... }

多catch块的时候，子类异常必须放在父类异常前面。因为JVM按顺序匹配，如果父类异常在前面，子类异常的catch块永远不会被执行，编译器会直接报错。

这个规则在写代码的时候容易违反，特别是当异常类型比较多的时候。IDE通常会提示你调整顺序，但理解背后的原因比依赖IDE提示更重要。

10. 我个人的一些实践体会

写了这么多年Java，关于throw和throws，有几个体会是踩过坑之后才真正理解的。

第一个体会是：异常处理的设计比异常处理的代码更重要。很多人写代码的时候是遇到异常了才想怎么处理，而不是在设计阶段就想清楚这个方法的异常契约是什么。结果就是异常处理代码散落各处，风格不统一，排查问题的时候到处找日志。如果能在设计接口的时候就明确"这个方法会抛出哪些异常、调用方应该怎么处理"，后面的代码会干净很多。

第二个体会是：不要害怕抛出异常。有些开发者喜欢用返回值来表示错误，比如返回null、返回-1、返回一个包含错误码的对象。这种方式在简单场景下能用，但在复杂业务里会导致大量的if判断，而且调用方很容易忘记检查返回值。异常的好处是强制调用方表态，不会静默失败。

第三个体会是：异常信息是写给未来的人看的。你写异常message的时候，想象一下三个月后的自己或者同事，在凌晨三点排查线上问题，看到这条message能不能快速定位问题。如果能，那这条message就是合格的；如果不能，那就需要补充更多上下文。

第四个体会是：受检异常和运行时异常的选择没有标准答案，但一个项目内部要保持一致。有的团队喜欢用受检异常强制处理，有的团队喜欢用运行时异常保持代码简洁。两种风格都有道理，最怕的是一个项目里两种风格混着用，调用方根本猜不到这个方法会不会抛受检异常。

最后一个体会是关于throws声明的维护。项目迭代过程中，方法的throws声明很容易变得过时——方法内部已经不抛某个异常了，但签名里还留着。这种"僵尸声明"会让调用方写很多无用的catch块。建议在代码review的时候顺便检查一下throws声明是否还有必要，该删的就删掉。