很久以前我就考虑这样一个问题：有这样一个函数，它的功能是从一个整数集合中返回最大的那个数，如何设计这个函数的签名了？当时没有得出令自己满意的答案，所以就搁浅了。今天重新思考，终于有所悟！现在把我思索的整个过程展现于此。
最直观的函数签名设计如下：

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

        我问了很多程序员，几乎都是这样处理的。我觉得这样设计函数很别扭，我喜欢直观简单的解决方案，无疑我最喜欢第一种签名形式，它很好的反应的函数的意图。而第二种了，它的设计不够好，除了不够直观外，还有什么更重要的缺陷？今天我知道了答案。
        首先，我们想想看，当eleList为null或者其中元素个数为0时，GetMaxElement知道怎么处理这件事吗？当然，不知道！因为在此函数中所有相关的上下文已经丢失了，那么谁知道处理的方法了？对，是调用GetMaxElement的调用方。调用方在调用GetMaxElement之前就应该检查eleList 是否满足条件。那么，这个条件是在哪里定义的了，目前的解决方案是在GetMaxElement函数说明文档中。

调用方这么做：

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

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

到这里，我总结了一个设计原则：
       不要让错误传播，在错误出现的发源地（萌芽期）就解决它！错误越是传播到最后，关于处理它的上下文就丢失得越多，对于错误的蔓延就越是爱莫能助！

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

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

对于实现Dbc.net有什么好的建议，欢迎和我讨论。我已经在博客园申请了Dbc.net的专栏http://www.cnblogs.com/DbcNet，欢迎你的加入！