近些年来，开发者可以通过代码契约（Code Contracts）这个研究性项目获得添加方法级别契约的能力，但这种方式存在许多问题，它所使用的命令式语法相当冗长，并且通过工具提供的语法支持也很差。无论是开发类库或是应用程序，要完整的利用这一契约特性，必须要运行某种编译后指令。总的来说，这是一个有趣的项目，但要真正变得实用，还需要第一等的编译器与语法的支持。

　　第 119 号提议——方法契约旨在提供这种支持。这一语法要求在方法签名与方法体之间定义前置与后置条件，与泛型的约束写法类似。下面这个示例展示了该语法的表现形式：

　　这条提议中共包含三个新的关键字。“requires”开头的语句负责处理前置条件，多数情况下将用于检查参数，但理论上也可以用于检查对象本身的状态。“ensures”开头的语句用于设定后置条件，它重用了“return”关键字，以指代该方法调用的返回结果。

　　快速失败还是抛出异常

　　类似于代码契约，这条提议最初的目的也是产生快速失败。这是一种相当激进的强制契约形式，任何对契约的违反都会立即导致应用的崩溃。在这种模型下，倾向于抛出异常的开发者不得不手动地进行标注：

　　对于该提议的这一部分，人们的反对相当激烈。

　　Nathan Jervis 写道：

　　HaloFour 也表示附和：

　　David Nelson 则提到了代码契约的经历：

　　稍后，他明确地列举了快速失败方式所导致的问题：

　　Aaron Dandy 则希望能够得到两种选择：

　　HaloFour 对以下观点表示同意：

　　异常类型

　　这条提议中比较容易接受的部分是 Argument 异常，编译器会将某个简单的 requires 语句转化为某个 ArgumentNullException 或 ArgumentOutOfRange 异常。如果 requires 语句检查的内容是对象的状态，那么它可以抛出一个 InvalidOperationException 异常。但如果该语句同时检查参数与对象状态呢？这种情况下要决定抛出何种异常会成为一个相当复杂的问题。

　　另外一个问题在于 ObjectDisposedException，因为没有什么标准方式能够表现一个被回收的对象。因此只能采取一些宽松的约定，检查是否存在某个叫做_disposed 或m_IsDisposed 之类名称的布尔型字段。这一点的重要性在于，InvalidOperationException 异常一般来说能够通过改变对象状态的方式进行恢复，而 ObjectDisposedException 永远做不到这一点。

　　另一方面，需要通过某种异常表示 ensures 语句出错。与 requires 语句不同，在 ensures 契约中的错误总是意味着在方法内部存在 bug。

　　本地化

　　假设我们采取了某种基于异常的方式，那么接下来的问题就是本地化了。对于基本的参数检查来说，编译器可以简单地生成包含英文文本的参数异常。但如果这些异常信息需要本地化为其它语言呢？如果选择使用简化的语法，就不会明确地抛出某个参数异常。这种情况下，或者需要通过某种渠道添加本地化的信息，或者不得不使用冗长的语法以显示本地化异常信息。

　　枚举与契约

　　目前为止所讨论的契约都是一种附加条件，而在 Fabian Schmied 所提出的提议中，编译器将允许省略那些绝对不会命中的 return 语句。

　　英文原文：C# Futures: Method Contracts