部件级别代码的容错(error tolerance)是提高了软件质量还是降低软件质量？

Published on Tue 02 Feb 2010 03:02 ( 1 month, 1 week ago)

加入一个新team, 发现在一个基本问题的处理方法上和自己过去的做法很不一样，甚至有些完全相反的意思。我当然一向是固执己见的，但是加入的毕竟有n多的牛人的team，有相当多经验比我丰富许多的人，所以有必要多思考一下。

这里描述两种对出错处理的方法，我先不说哪是我相信的，哪是我在怀疑的。

方法A: Error tolerance as much as possible

每个部件自己确定对依赖部件的调用产生的错误的“容忍”程度，并且尽量根据自己所在部件的需求来对底层的出错进行处理。对于可以忽略的错误，或者可以handle的错误，在这一层处理掉；对于无法处理的错误，抛到高层去处理，根据需要决定是否抛出新的错误类型。

优点：每个层次都清楚地了解会发生哪些错误，并且了解这些错误如何处理。（知道自己不能处理也是一种处理）

缺点：一些底层的错误可能永远不会被发现，因为这些错误已经被其高层给处理掉了。糟糕的错误处理方式可能会掩盖长期存在的错误。

方法B: Fail fast and fail early

对大部分错误（除非是已知需要处理的，比如I/O的错误等可能出错的且不属于代码的错误）的发生, 立刻中止并返回错误。

上层部件不处理大部分下层产生的错误，除非这个错误是被预期可能产生的。

优点：任何未知的错误都会导致fail, 通过快速fail 在早期发现未知的错误并fix掉。质量较差的部件的问题不会被掩盖。

缺点：任何逻辑上认为不应该产生的错误都可能导致整个软件的失败，在部件较多的时候，一些可被预期但却很少容易发生的错误会被遗漏处理，从而导致后期软件交付后失败。

---

其实两者并非黑白排斥关系，实际情况下是应该两者结合的，但是在一个大的系统中，可能需要一种哲学或者指导原则，是应该fail fast还是fail tolerance, 也就是偏向哪种更多些。

我的问题是，哪种哲学会导致软件的质量更高？这貌似一个悖论，方法A会掩盖一些底层错误，当时一个软件如果对用户而言错误被自我处理了，这些底层的错误是否是一个错误呢？方法B能早期发现错误提高软件质量，但是这种低概率的疏漏如何才能保证不会发生?

说明：这里的部件是泛指，可以是一个class, 模块、库、组件、甚至一个独立的应用。

Custom Search