程序员修炼之道系列 | 死掉的程序不会说谎
原创-
发表时间 2021-07-14
-
阅读数 3393
-
最后编辑:程一凡 于 2024-07-02 16:15:04
一、“不可能事件”的发生
在软件设计中,大家有没有过“这不可能”的心态。“这不可能”会让我们说服自己错误不可能发生,然后选择忽略他人或程序发出的预警。
实际上,在我们意识到某些地方出了问题之前,“不可能事件”就已经发生了。如果我们因“不可能”心态忽略了这些小的错误,反而会面临一个更糟糕的境地。
当出现了“不可能”的错误时,我们应如何正确处理它呢?
二、暴露问题优于隐藏问题
当程序出现异常状态,此时放任异常的程序继续执行可能会造成更大的损失,因此,有时候需要让程序尽早崩溃。
1986年1月28日,美国“挑战者”号航天飞机升空73秒后,“挑战者”号突然爆炸解体,机上7名宇航员在此事故中丧生。
NASA当时给出了一个答案:这起事故的主要原因是内部沟通机制不完善。但他们隐瞒了一个细节:在“挑战者”号升空之前,一名工程师发现了一处问题。该工程师建议NASA推迟发射,然后对飞机进行全面检修。但NASA决定按照原计划发射,发射计划就此埋下了隐患。
同样,尽早崩溃也是为了防止项目研发中发生类似的不可控事件。在实际应用中 ,尽早崩溃有如下解释:尽早崩溃并非不容错,是指程序员不必因过分担心未知的错误,转而进行面面俱到的防御性编程。
如果程序员无法分析错误的来源,并精准定位错误的发生情景时,可以尽早崩溃该进程,在合适的时机重启进程。因为暴露问题优于隐藏问题。
三、尽早崩溃也是有条件的
凡事都有度,过犹不及。尽早崩溃也是如此。在以下情况中,尽早崩溃就失去了它的效用。
1.已知错误
如果能够定位问题,比如读文件前没有判断文件是否存在已知错误,就没有必要让程序崩溃。
2.进程无法恢复
如果在无法恢复上下文的情境中,崩溃掉程序所付出的成本是巨大的。试想一下,你会使用一个在通话的时候随时自动挂线的语音聊天软件吗?
用尽早崩溃的方式构建程序,这意味着不再需要防御性编程——如果出现错误,那就根据具体情况来灵活处理,处理不了就让它崩溃!一个死掉的程序通常比一个瘫痪的程序造成的损失要小得多。