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