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的修复。

kejinlu /
Published under (CC) BY-NC-SA in categories Programming  tagged with Java