过去写代码时,我总觉得 “错误处理” 是 “可有可无的附加项”—— 只要自己测试时没遇到报错,就不用写 try-catch,不用判断空值。但读了《代码大全 2》中 “错误处理” 的章节,才意识到错误处理是代码的 “安全气囊”,能在意外发生时避免程序崩溃,甚至减少线上故障。
书中有个比喻很形象:“错误处理就像汽车的安全带,平时用不上,但关键时刻能救命”。我曾开发过一个 “导入 Excel 数据” 的功能,当时只测试了 “格式正确的 Excel”,没处理 “空文件”“格式错误”“数据缺失” 这些情况。上线后,有用户上传了一个空 Excel,程序直接抛出异常崩溃,还导致整个页面卡住。后来按照书中的建议,我加了三层防护:一是判断文件是否为空,二是验证 Excel 格式是否正确,三是对每一行数据做非空检查,并且在每个环节都返回明确的错误提示(比如 “请上传非空的 Excel 文件”“第 5 行‘姓名’列不能为空”)。修改后,即使出现错误,程序也能正常运行,用户也知道该怎么修正问题。
书中还强调,错误处理要 “具体”,避免 “吞掉错误” 或 “模糊提示”。比如不要只写 “try { ... } catch (Exception e) { return null; }”—— 这样出了错,既不知道错在哪,也没法排查;而应该捕获具体的异常(比如 FileNotFoundException、IOException),记录详细的错误日志(包括错误位置、参数信息),并返回清晰的提示。我之前写 “调用第三方接口” 的代码,用了笼统的 Exception 捕获,有一次接口返回 500 错误,日志里只写了 “调用接口失败”,查了半天也没找到原因 —— 是参数错了?还是接口超时了?后来我按照书中的方法,捕获了 HttpException,记录了请求参数、响应状态码、错误信息,很快就定位到是 “参数格式不符合接口要求”。
现在我写代码时,会主动想 “这里可能会出什么错?”—— 用户输入错误、接口调用失败、数据为空、权限不足…… 然后针对性地做处理。错误处理虽然会增加几行代码,但能让程序更健壮,减少线上故障。《代码大全 2》教会我的,是 “敬畏错误” 的态度 —— 编程不是 “追求不出错”,而是 “做好出错的准备”。