程序员修炼之道系列 | 死掉的程序不会说谎

一、“不可能事件”的发生

在软件设计中，大家有没有过“这不可能”的心态。“这不可能”会让我们说服自己错误不可能发生，然后选择忽略他人或程序发出的预警。

实际上，在我们意识到某些地方出了问题之前，“不可能事件”就已经发生了。如果我们因“不可能”心态忽略了这些小的错误，反而会面临一个更糟糕的境地。

当出现了“不可能”的错误时，我们应如何正确处理它呢？

二、暴露问题优于隐藏问题

当程序出现异常状态，此时放任异常的程序继续执行可能会造成更大的损失，因此，有时候需要让程序尽早崩溃。

1986年1月28日，美国“挑战者”号航天飞机升空73秒后，“挑战者”号突然爆炸解体，机上7名宇航员在此事故中丧生。

NASA当时给出了一个答案：这起事故的主要原因是内部沟通机制不完善。但他们隐瞒了一个细节：在“挑战者”号升空之前，一名工程师发现了一处问题。该工程师建议NASA推迟发射，然后对飞机进行全面检修。但NASA决定按照原计划发射，发射计划就此埋下了隐患。

同样，尽早崩溃也是为了防止项目研发中发生类似的不可控事件。在实际应用中 ，尽早崩溃有如下解释：

尽早崩溃并非不容错，是指程序员不必因过分担心未知的错误，转而进行面面俱到的防御性编程。

如果程序员无法分析错误的来源，并精准定位错误的发生情景时，可以尽早崩溃该进程，在合适的时机重启进程。因为暴露问题优于隐藏问题。

三、尽早崩溃也是有条件的

凡事都有度，过犹不及。尽早崩溃也是如此。在以下情况中，尽早崩溃就失去了它的效用。

1.已知错误

如果能够定位问题，比如读文件前没有判断文件是否存在已知错误，就没有必要让程序崩溃。

2.进程无法恢复

如果在无法恢复上下文的情境中，崩溃掉程序所付出的成本是巨大的。试想一下，你会使用一个在通话的时候随时自动挂线的语音聊天软件吗？

用尽早崩溃的方式构建程序，这意味着不再需要防御性编程——如果出现错误，那就根据具体情况来灵活处理，处理不了就让它崩溃！一个死掉的程序通常比一个瘫痪的程序造成的损失要小得多。