2017-05-04 01:31
如果app出问题了，一般来说有两种情况可能会发生：
一是默默地咽下苦果，假装没有事一样。
二是在大哭中崩溃。
举例来说，你有一个对象，不知道怎么成了null，从而引发了致命的后果（不，我不是在说失恋自杀的事）。正常来说应该像第二种情况，抛出异常，app崩溃，自动关闭或重启。但是你也可以采取防御式编程，加if检查，catch异常。于是app还可以继续运行，只是用户希望进行的功能被中止了，而且有时连错误提示都没法给用户，点了按钮结果什么都没有发生。
理想情况是能将出错信息通知用户。上面这两种情况当然都很糟糕。问题是哪个相对更不糟糕一点？
编程者直觉上可能会认为第一种更可接受一点。大家都不喜欢崩溃。app还在跑，用户没准会重试。但用户的心理往往不是这样。崩溃了也许是自己操作不对，也许是手机买便宜了，不一定就会把锅甩给谁。但功能失效是不可原谅的，一定会说你的app坏了。
而且更重要的一个点是：出错即崩溃的方式下，很多错误会在开发测试阶段被发现，好过测试一切正常、上线了才发现问题。
所以防御式编程不能简单理解为用if捕捉消灭异常，更重要的是用else反馈异常。假装没事最可怕，一定要说出来（不，我不是在说失恋后抑郁自闭的事）。如果条件不允许，那还不如就让它崩溃，也算是“说出来”的一种方式。
这就是所谓crash fast的“进击式编程”方式。