原文：

 

 

Fail Fast

Fail Fast从字面上看是“快速失败”的意思，或者叫做“速错”，其含义就是让可能发生的错误尽早的被发现。 无论是人类，还是代码这个道理都是适用的。我们在做事的时候，犯错误是很常见的，但是我们应该尽量使得错误发生之初就被发现，并找出原因进行纠正。一开始不重视或者变相的处理了，这会使得错误延后，反而使得损失增大。 还有个事例就是创业，我们就要抱着“如果要失败那就快点”的心态，加快自己前进的步伐。 哈哈，说远了，今天主要说的是程序设计中的Fail Fast。

在我们软件开发的过程中，当碰到问题了，我们第一步就是重现问题，然后进行debug，找出问题的原因，但往往有些bug隐藏的比较深，经过n次特定的操作的在特定的环境下才会重现，或者出错后，报错的stack traces的没有指出错误的真正起点。
所以我们设计一个Fail Fast的系统显得很重要了。
很多人设计的系统，为了增强系统的健壮性，自动的将系统中出现的问题处理掉，并继续运行，但是在未来的某个时间引发奇怪的错误。
而fail fast的系统的做法却是相反的，当有问题发生，立即出错，并将出错信息显示出来。这样bug就很容易被发现，而不会进入到最终的产品中。
比如下面的代码片段,假设maxConnections从一个配置文件中读取最大连接数这个数值， 当发现读取到的值为null的时候，我们一般有两种做法，直接返回null或者返回一个默认值。
(在JDK的HashMap的实现中也遵循fail fast原则，当获取遍历游标iterator之后，如果别的线程对map进行修改等操作会抛出异常的，因为这样会使得算法执行的环境发送变化，导致遍历过程中可能发生错误。)

public int maxConnections() {
       string property =getProperty("maxConnections");  if (property == null) {
            return 10;   } else {
           return property.toInt();  } }

但是这在fail fast的原则下则应该如下

public int maxConnections() {
             string property =getProperty("maxConnections");        if (property == null) {
               throw new                      NullReferenceException (                           "maxConnections property not found in"                           + this.configFilePath);       } else {
              return property.toInt();      } }

假设上面的代码是某个web应用的一部分，当某次升级的时候，不小心将maxConnections写错了，或者不小心删除了，那么如果采取默认值的情况的话，可能程序不会报错，但是运行之后可能会发现因为连接数变小了而使得应用很慢，且这个错误不便于查找，但是如果直接抛异常的话，错误就显而易见了。

在很多时候，在系统中我们需要建立自己的错误异常处理体系，比如编写一系列的assert检测方法，并定义自己的异常类型，在正确的地方抛出异常。

fail fast的方式可能使你感觉到软件的健壮性不是很好，的确它让我们更容易的找到错误，那么当我们最终将软件部署成产品的时候，还需要这样的写法么，很多时候我们在发布的时候都回将assert关闭，为了避免因为错误使得程序crash掉，但是真的有必要这么做么，其实没有必要，有时候线上的错误很少会发生，如果发生了错误，而不直接显示，那么我们开发人员找错误的时候，首先就需要重现问题，而这个可能很难重现出来。当然我们可以使得异常的方式处理的友好些。比如跳出一些错误异常窗口，然后询问是否将异常发生时的状态和错误信息发送给开发人员。 这样将有助于软件bug的修复。