做软件构造实验的前三个Lab，我的心态一直是“把功能写完，把测试跑绿，收工”。到了Lab4，画风突然变了：导师不再关心你写不写得出新功能，而是让你拿着上一阶段已经写好的代码，去对抗各种你根本想象不到的输入和运行环境。第一次看到实验题里“对不合法输入给出合理反应”这句话时，我还觉得这不就是到处catch一下的事，真动手才发现完全不是这么回事。这篇文章就把我在某高校软件构造课程Lab4里的完整实践做个复盘：从异常处理策略怎么设计，到断言用在哪、日志怎么打，再到一次真实空指针错误的排查全过程，最后列几个评分时最容易被扣分的点。正在写Lab4的同学可以直接看第二、三、五节，已经是工作状态、想补健壮性地基的工程师，建议把第四节的排查链路完整读一遍。

1. 这轮实验的真正目标：从“能跑”变成“怎么折腾都不崩”

1.1 正确性、健壮性：为什么是两种不同的软素质

前三个Lab练的大多是正确性：输入合法时，程序行为符合规格说明。Lab4转向了另一个维度——健壮性：输入不合规、环境异常时，程序能不能不崩溃、不静默产生错误结果、或者至少给出足够明确的失败信号。

这两个词看着像一回事，实际差很远。正确性回答的是“我该做的做对了吗”，健壮性回答的是“事情变坏时我有没有兜住”。举几个 Lab4 里常见的边界场景：用户传了 null、传了超大的整数、文件是空的、文件带 BOM 头、文件中间少了两列、并发读同一个文件、磁盘写入失败。程序每一种情况都得有一个明确可预期的反应，而不是随机挂掉或者悄悄算出一堆废数据。

当时实验要求里还提到要在编译期引入静态检查和代码覆盖率统计，这一点也帮我提前发现了很多很隐蔽的“非空判断缺失”和“未使用变量”。配置检查规则时不要只追求覆盖率数字，后面第五节会展开讲这个坑。

1.2 从上一阶段的设计底座开始

Lab4通常不会让你从零写，一般是在 Lab3 已经做好的数据读取、解析、统计模块上做健壮性增强。这一步很关键：先别急着改代码，而是把现有代码里所有依赖外部输入和资源的入口列出来。

我习惯列一张“薄弱点清单”，按输入来源分组：

• 配置文件读取：缺字段、字段类型错、文件不存在、文件权限不足；
• 命令行参数：数量不对、格式非法、路径不存在；
• 文件行解析：列数不对、数值越界、编码异常、空行规则不统一；
• 资源使用：打开的文件流是否关闭，线程池是否在场景结束后的合适时机被关闭。

每个入口至少想清楚三件事：不合法输入长什么样、当前代码遇到它时会怎么反应、期望它应该怎么反应。这张表既是后续编码路线图，也是实验报告里很有分量的“健壮性分析”章节。很多同学上来就埋头改代码，改到哪算哪，最后报告里没什么可写，反而吃亏。

1.3 我把实验拆成了五件事

真正动手前，我把 Lab4 的产出拆成五个可验证的小目标：

1. 异常处理策略：为不同错误类型定义清晰的异常体系，明确每一层该 catch 还是该抛；
2. 防御式校验：区分“外部输入校验”和“内部不变量断言”，用对工具；
3. 日志与可观测性：关键路径上记录足够定位问题的日志，而不是靠猜；
4. 测试补强：不只是提高覆盖率，而是把异常路径和边界输入真正测到；
5. 调试记录：把一次完整的问题排查过程沉淀成实验报告素材。

下面按这几条展开。

2. 异常处理设计：怎么catch才不算“摆了动作”

2.1 先回答一个问题：这个异常到底该谁负责

处理异常的本质，是确定责任边界。一个方法发现自己没法完成契约时，应该把“我做不到”这个信号明确地通知出去，而不是假装一切都好。正常返回值是给调用方用的业务结果，异常则是“这个方法的能力边界已经到头了”的传达方式。

实验中很容易纠结用 checked 还是 unchecked。我当时的判断原则是：

• 如果调用方完全可以通过前置条件避免这个异常，比如文件路径不存在，用 checked 异常提醒调用方处理，更安全；
• 如果是调用方无法提前预料的输入问题或程序缺陷，比如配置文件格式错误、数值转换失败，用 unchecked 异常更合适，因为强制每个调用点都 catch 反而会把异常处理写成一堆空 catch；
• 如果是一个系统级故障，比如底层资源耗尽，也走 unchecked，让最外层统一兜底。

Lab4 里最常见的正确设计，是定义几个自定义的 RuntimeException，在业务入口处做统一拦截，把堆栈信息写入日志，同时向用户输出一句可读的提示。这样代码主体不用到处try-catch，错误信息又不会丢。

2.2 空catch块为什么会成为评分重灾区

很多同学拿到健壮性需求的第一反应，是把所有可能抛异常的代码全部包进catch，然后写一个空的 catch 块。我见过最极端的写法长这样：

try { int score = Integer.parseInt(fields[2]); } catch (Exception e) { // 忽略 }

程序确实不崩了，但所有错误信号都被吞掉，日志里什么都没留下。后面一旦有人发现统计结果不对，只能靠肉眼一行行看数据。这种代码在实验评分里几乎是必扣分项，因为健壮性不是“不崩就行”，而是“崩的时候要有迹可循”。

同样这段逻辑，即使是想给脏数据一个默认值，也应该至少这样写：

int score; try { score = Integer.parseInt(fields[2]); } catch (NumberFormatException e) { logger.warn("第{}行字段score的值{}不是合法整数，使用默认值0", lineNo, fields[2]); score = 0; }

这里有一个关键区别：NumberFormatException是具体异常，Exception是兜底异常。解析单个字段时能够精确知道会发生什么，根本不需要 catch 那么宽。把异常类型收窄，往往比空 catch 更早暴露出你没想到的例外情况。

2.3 异常类型的粒度：把异常本身写成文档

我见过一种很容易被扣分的写法：整个项目里只有一个自定义异常MyException，所有方法都throws Exception。结果就是调用方拿到异常后完全不知道发生了什么，根本没法区分“配置格式错”和“底层资源不可用”是两类完全不同的问题。

异常类型本身就是面向调用方的文档。Lab4 阶段我建议把异常拆到业务语义级别：

这样做的收益很直接：你在日志里看到ConfigFormatException，不需要再翻代码，就已经知道是配置问题而不是数据问题；看到DataParseException里的行号，就能直接定位到数据文件里的具体一行。

2.4 一个带上下文的自定义异常例子

以一个配置解析场景为例。解析配置时发现第 3 行的timeout字段写了一个非数字字符串，错误不能只是“parse error”，而要直接说清楚是哪个文件哪一行哪个字段。

public class ConfigFormatException extends RuntimeException { private final String source; private final int lineNo; public ConfigFormatException(String source, int lineNo, String fieldName, String badValue) { super(String.format("配置解析失败: [%s] 第 %d 行字段 [%s] 的值 '%s' 不合法", source, lineNo, fieldName, badValue)); this.source = source; this.lineNo = lineNo; } public String getSource() { return source; } public int getLineNo() { return lineNo; } }

这里有两个设计细节值得说。第一，继承 RuntimeException 而不是受检 Exception，是因为调用方很难提前预判某个字段值到底合不合法，强制 checked 只会逼出一堆无效 catch。第二，异常消息里把所有定位信息都拼进去了，上层日志只需要原样记录 message，就能直接还原完整错误场景。自定义异常里的source和lineNo字段则是留给程序化处理用的，比如测试断言时可以精确断言“异常发生在第3行”。

3. 断言、防御式校验与fail-fast：把程序的底线焊死

3.1 assert的正确用法：内部不变量，而不是外部输入

这是 Lab4 里最容易被误解的一个点。Java 的assert默认是关闭的，只有显式加了-ea运行时参数才生效。所以拿assert params != null去校验用户输入，等于什么都没做。更关键的是，断言表达的是“我的代码内部假设永远不会被违反”，它本就不是设计来面向外部输入的。

我当时花了一点时间把整个程序里的“外部输入校验”和“内部不变量”分开列了一遍，规则很简单：

• 外部输入、文件内容、用户参数，用if + 抛异常；
• 类内部不变量、算法中不可能为 false 的条件，用assert；
• 两种情况不要混用。

3.2 fail-fast vs 部分成功：批量导入场景的取舍

处理多行数据时，会遇到一个很现实的问题：前面 100 行都正常，第 101 行格式坏了。你是让整个任务失败，还是跳过坏行继续后面 99 行？

我实验里一开始选择的是“跳过坏行继续”，理由是尽量保留数据。后来被师兄提醒后改了回来：大多数场景下，批量导入要的是原子性，宁可全部失败，也不能让用户看到“任务成功了但中间少了三行”。Lab4 的评分逻辑也是这样——失败要明显，不能悄悄吞掉。

这里的实操要点在于：如果走 fail-fast，就一定要保证失败后没有副作用。比如先把所有行解析并校验通过，再统一写入目标对象。否则前 100 行已经写进去了，第 101 行报错回滚，状态就很脏。正确做法是在导入流程里加一个“预校验阶段”，全部通过后再真正提交。

如果确实需要“跳过坏行继续”的策略，那也必须在结尾输出一份摘要，明确说“共导入 100 行，跳过 3 行，原因分别是第 12 行缺少字段、第 67 行数值非法”。绝对不能静默完成。

3.3 RepOK机制与构造器后的自我检查

软件构造课一直在强调抽象函数和表示不变量。Lab4 里最有价值的落地方式，就是给每个核心类写一个checkRep方法，在构造器、关键 mutator 的出口调用一次，发现不变量被破坏就立刻抛异常。

public class StudentRecord { private final String id; private final int score; public StudentRecord(String id, int score) { this.id = id; this.score = score; checkRep(); } private void checkRep() { assert id != null && !id.isBlank() : "id不能为空"; assert score >= 0 && score <= 100 : "score必须在0~100之间"; } }

我见过不少同学觉得这种检查“多此一举”，认为自己的代码不会有问题。但 Lab4 里的输入来自各种文件，某一行字段为空、某个数值越界都很常见。构造器里没有checkRep，这些坏数据就会一直传到后面，在最深的某个方法里爆炸，到那时候堆栈已经绕了三个模块，定位成本成倍上升。提前在入口拦住，成本低得多。实验环境里直接调checkRep完全没问题，性能心得其实可以等到正式工程再考虑。

4. 日志与一次“看起来不可能”的空指针排查全过程

4.1 日志格式设计：别把System.out.println带进实验

很多同学在 Lab3 里调试时习惯System.out.println，到了 Lab4 还继续这么干。但实验一跑起来，几十行输出混在一起，根本看不出先后顺序，更别说把“同一笔业务处理到哪一步”串起来。

我采用的日志格式很简单：

2025-01-12 10:31:22.344 [main] WARN ConfigLoader#load - 缺少配置项timeout，使用默认值3000 2025-01-12 10:31:22.371 [main] ERROR DataImporter#import - 文件data.csv处理失败: 第58行字段score值'abc'非法

这行格式里有几个要素缺一不可：时间戳用于还原时序；线程名用于排查多线程问题；日志级别区分信息、警告、错误；类名#方法名直接指示错误发生的业务位置；最后的消息内容带上具体变量值，而不是笼统的“处理失败”。这样每行日志都能独立回答问题。

日志级别也要形成惯例：输入不合法、字段缺失这类外部问题记warn；内部异常、系统资源故障记error；正常处理步骤不记 info，除非确实需要跟踪进度。级别越清晰，过滤日志时越容易定位。

4.2 异常日志不能只打e.printStackTrace

e.printStackTrace()是实验里最常见的问题之一。它把堆栈打到标准输出，够原始，但缺少业务上下文。我某次排查问题时日志里只有一行堆栈，完全看不出是哪份文件、哪条记录触发的。

正确做法是把上下文和堆栈一起记录。实验代码里我这样写：

try { processLine(line, lineNo); } catch (DataParseException e) { logger.error("处理文件{}时，第{}行解析失败。原始内容: {}", fileName, lineNo, line, e); }

注意最后一个参数把异常对象传进去了，日志框架会打印完整堆栈。这样日志里就能把“哪个文件”、“第几行”、“什么业务动作”、“底层什么异常”串成一条完整线索。

4.3 排查链路：复现、隔离、看日志、修根因、回归验证

这是 Lab4 里让我印象最深的一次问题排查。某个解析字符串的方法在单元测试中各种用例都通过了，但集成测试读取某个示例文件时，总在运行到一半时抛NullPointerException。最诡异的是堆栈只指向某个toString方法，完全看不出来真正的原因。

我按下面的链路一步步排查：

1. 固定输入复现。把出问题的文件复制成只读副本，重复跑，确认 100% 必现。这一步保证了后面每次改动都能验证效果。
2. 看日志找停止位置。日志显示处理到第 58 行后就没有后续输出了，说明问题大概率发生在这行数据被解析或者格式化时。
3. 隔离方法。通过减少输入文件行数做二分，把范围逐渐缩小，最后发现只要文件里存在某个字段为空的记录，问题就会复现。
4. 追根因。打开解析代码，发现解析器对一个可选字段直接返回了 null，上层却在后续把 null 拼接进了业务对象，最终在toString里触发 NPE。问题的本质不是 NPE，而是解析层没有对可选字段做空值策略。
5. 修根因。最后选择在解析层做明确处理：如果必填字段为 null，直接抛DataParseException并附带行号；如果可选字段为 null，则统一转为默认值，不允许把 null 继续向上传。
6. 回归验证。把单测、集成测试全部跑一遍，确认修复没有影响其他正常路径，同时专门补了一条“字段为空”的测试用例。

这次排查给了我一个很深的教训：NullPointerException的堆栈位置往往只是“爆炸现场”，而不是“事故源头”。如果日志能提前暴露解析层收到的坏数据，这个问题的定位时间能从半天缩短到十分钟。

4.4 把调试过程写成实验报告的有效素材

实验报告的“测试与调试”部分，很多同学写的是“程序运行正常，无重大问题”。但真正有价值的是像上面这样完整的排查过程：从现象入手，通过日志和二分法隔离，最终定位根因并回归验证。

我把这次空指针排查写成了报告里的一小节，没有用华丽的描述，只按“现象-假设-验证-根因-修复”五段记录。导师给的反馈是这种“能看到思考过程”的记录比单纯代码更能体现软件构造能力。毕竟健壮性本身就是一个不断发现边界、处理边界的过程，你把边界是怎么发现的写出来，比把边界一个个列出来要有说服力得多。

5. 最容易扣分的五个隐藏雷区

5.1 覆盖率很高却全是happy path

覆盖率数字很好看，点开却发现所有测试都在走正常路径，异常分支几乎没有覆盖，这是我见过最常见的无效努力。Lab4 评分时，测试部分看的不是“覆盖率多少”，而是“异常分支有没有真的被触发”。

改进方法很朴素：每写一个异常处理分支，配一条专门触发该分支的测试。比如配置文件里故意少写一个字段，断言“抛出 ConfigFormatException”；数据文件某一行故意给一个非数字数值，断言“抛出 DataParseException”。测试代码里要能看到失败路径的存在。

5.2 方法签名上挂着硕大的throws Exception

这是过度抽象的反面教材。所有方法都写throws Exception，调用方 catch 时只能用catch (Exception e)，一切又回到了“看不清异常类型”的老路上。正确做法是让签名精确表达意图：文件读取方法抛IOException，配置解析方法抛ConfigFormatException，业务逻辑里的意外状态抛自定义运行时异常。签名本身就是调用契约的一部分。

5.3 异常消息没有上下文

“数字格式错误”这种消息放在实验代码里，等于没写。配合前面自定义异常的实践，每条异常消息都应该回答三个问题：什么文件或对象、哪一行或哪个字段、具体的坏值是什么。养成这个习惯后，你会发现调试时看异常消息就够了，连 debugger 都不用开。

5.4 资源关闭与线程清理

Lab4 涉及文件读取、流操作时，很多同学在资源关闭上翻车。要么忘记关，要么在 catch 里关，一旦前面抛了异常，关闭代码根本执行不到。规范写法是 try-with-resources，Java 里这样写：

try (BufferedReader reader = Files.newBufferedReader(path)) { String line; while ((line = reader.readLine()) != null) { // 处理行 } } catch (IOException e) { logger.error("读取文件{}失败", path, e); }

另外如果实验里启了多线程或线程池，要提供明确的关闭时机。常见评分观察点是“测试跑完后进程还挂在那里不退出”，多半是线程池没有关闭。用executor.shutdown()或把线程设为 daemon，都能避免这种问题。

5.5 没有区分“业务异常”和“程序缺陷”

这个点最隐蔽。空指针、数组越界本质上属于程序缺陷；配置格式错、数据字段缺失属于业务异常。两者处理方式完全不同：程序缺陷要尽快暴露并修复，业务异常可以转化成用户可懂的错误提示。

我见过把空指针包装成“数据异常”返回给用户的代码，结果就是真正需要修复的 bug 全被埋在了“用户操作有误”的假象下面。实验评分里只要看到这类混淆，扣分几乎跑不掉。正确做法是：程序缺陷让异常继续向上抛，日志记录 error；业务异常则转成明确提示，日志记录 warn。

6. 从Lab4带走的习惯与实践技巧

6.1 把“先想异常”变成肌肉记忆

做完 Lab4 后再写新方法，我的习惯变了：先问入参可能是什么，哪些值会破坏现有逻辑，调用方有没有办法提前避免，然后才写主体代码。表面上多花了两分钟，实际上省掉的是后面几小时的 debug 时间。工作中做接口参数校验、配置文件读取、外部服务降级时，我全在沿用这套思路——先想底线在哪，再想功能怎么做。

6.2 用一个畸形输入脚本提前炸出弱点

最后分享一个实验阶段很管用的小技巧：写一个简单的脚本，批量生成畸形输入喂给被测程序。我会生成超长字符串、空字符串、只有一列数据的 CSV、带 BOM 的文本、随机 Unicode 字符、数值超过 int 范围的整数，然后逐条观察程序会不会崩、会不会卡住、会不会出现不合理结果。

这个技巧本质上就是轻量级的模糊测试，不需要框架，一个循环加随机数生成器就能跑起来。它能非常高效地把脆弱点提前暴露出来，而且实验报告里写“额外构造了畸形输入集合进行测试”，本身就是加分项。我当时用它炸出了三四个手写测试完全没覆盖到的边界问题。

6.3 个人体会

写 Lab4 那几天我一度很烦躁：功能明明早就写完了，为什么还要花一个礼拜补异常、补日志、补测试。后来工作第一周遇到线上问题，日志打得太烂，定位故障花了整整一晚上，才明白那门实验让我练的东西是会一直跟着人走的。

如果你现在也卡在 Lab4 里，别急着把代码推倒重写，更别到处空 catch 来救火。先把异常边界和日志链路理清楚，再用畸形输入把弱点炸出来，剩余的工作会变成一边按流程填坑、一边把坑写进报告的过程，而不是在乱试中反复横跳。