函数设计之美－－函数需要返回错误码吗（一）？

很久以前我就考虑这样一个问题：有这样一个函数，它的功能是从一个整数集合中返回最大的那个数，如何设计这个函数的签名了？

当时没有得出令自己满意的答案，所以就搁浅了。今天重新思考，终于有所悟！现在把我思索的整个过程展现于此。

最直观的函数签名设计如下：

int  GetMaxElement(ArrayList eleList) ;

乍看之下，很好，很直接的反应了意图。稍微深入一点就发现，如果eleList为null或者其中元素个数为0，GetMaxElement返回什么了？第一反应，修改签名为下面的形式：

bool  GetMaxElement(ArrayList eleList , out   int  result) ;

我问了很多程序员，几乎都是这样处理的。我觉得这样设计函数很别扭，我喜欢直观简单的解决方案，无疑我最喜欢第一种签名形式，它很好的反应的函数的意图。而第二种了，它的设计不够好，除了不够直观外，还有什么更重要的缺陷？今天我知道了答案。

首先，我们想想看，当eleList为null或者其中元素个数为0时，GetMaxElement知道怎么处理这件事吗？当然，不知道！因为在此函数中所有相关的上下文已经丢失了，那么谁知道处理的方法了？对，是调用GetMaxElement的调用方。调用方在调用GetMaxElement之前就应该检查eleList 是否满足条件。那么，这个条件是在哪里定义的了，目前的解决方案是在GetMaxElement函数说明文档中。

调用方这么做：

ArrayList eleList  =  

if ((eleList == null )  ||  (eleList.Count == 0 ))
{
   //处理错误
}

int  max  =  GetMaxElement(eleList) ;

由于调用方知道怎么处理eleList为空和个数为0的错误的上下文，所以它很容易解决这个问题。如果采用第二种签名，有何缺陷了？在第二种签名情况下，调用方通常这么做：

ArrayList eleList  =  

int  max  =   0  ;
bool  succeed  =  GetMaxElement(eleList ,  out  max) ;

if ( ! succeed)
{
    //唉，我也不知道怎么处理了
}

到if(!succeed)语句时，调用方已经不知道GetMaxElement返回的错误是不是由eleList为空和个数为0引发的，错误的根源丢失了，所以调用方对返回的false真是爱莫能助、唯有叹息了！

到这里，我个设计原则：

        不要让错误传播(出现)，在错误出现的发源地（萌芽期）就解决它！错误越是传播到最后，关于处理它的上下文就丢失得越多，对于错误的蔓延就越是爱莫能助！

为GetMaxElement方法加上注释后是这个样子：

// 调用此函数前请确保eleList不为null，且其中元素个数大于0
int  GetMaxElement(ArrayList eleList) ;

这实际上是限制了一个前置条件，关于前置条件和后置条件的更多资料可参考“契约式设计”！将到这里，我考虑在.NET平台上实现一个契约设施Dbc.net，该设施将在运行时自动检测前置条件、后置条件等。很有可能像下面的样子：

[PreCondition(eleList  !=   null )]
[PreCondition(eleList.Count  >   0 )]
int  GetMaxElement(ArrayList eleList) ;

晚了，就先到这里吧！对于实现Dbc.net有什么好的建议，欢迎和我讨论？