Delphi 12 异常处理清单：避免吞错与误判

异常处理这件事，很多 Delphi 项目不是不会写，而是写得太随意。尤其是吞错、误判和兜底过度，后期比不捕获还麻烦。这篇是我自己的排坑清单。

我现在回头看很多 Delphi 项目的线上问题，真正难排的往往不是“异常太多”，而是“异常被处理得太早、太宽、太含糊”。表面上代码到处都有try...except，看起来好像很稳，实际上很多错误一旦被顺手吃掉，后面只会以更隐蔽的方式爆出来。

我自己最警惕的一种写法，就是为了让程序“别报错”，在大段逻辑外面套一个宽泛的异常处理，然后统一弹一句失败提示，甚至什么都不做。这样写短期确实省事，但代价是你把错误上下文全丢了。出了问题之后，既不知道是哪一步失败，也不知道状态是否已经部分写入，排查成本会非常高。

我现在更倾向于把异常处理分层：能就地恢复的地方就明确恢复，不能恢复的错误就别假装处理掉，至少要保留足够日志，让后面的人看得见问题发生在什么阶段。尤其是数据库写入、文件操作、线程任务和外部接口调用，这些位置的异常如果处理得模糊，最终都容易变成用户口中的“偶发问题”。

另一个经验是，不要把业务判断和异常处理混成一回事。比如“查不到记录”通常是业务结果，不一定是异常；“配置缺失导致关键对象没法初始化”则更像系统状态错误。这两类情况如果都用同一种兜底方式处理，代码会越来越难理解，后面也容易误判真正的故障等级。

我也会特别注意 finally 里的清理逻辑是不是安全。有些代码为了保证释放对象，把一堆收尾动作全塞进去，但一旦中间再抛异常，原始错误反而被覆盖。这个坑在老项目里很常见，尤其是对象生命周期复杂、还夹着界面更新的时候。所以我现在对异常处理的要求很直接：别吞错，别误判，别假装一切都被处理好了。异常机制的价值不是让程序“看起来不报错”，而是让错误能被正确识别、正确收口、正确追踪。