是否有任何理由不使用代码合同的运行时合同检查?

在一些非任务关键型应用程序中,您实际上可能希望让错误在发布版本中滑动,而不是在用户面前抛出错误对话框。最终用户可能永远不会注意到的小错误可能会导致合同检查失败并损害用户体验。

我觉得用两份合同都不合适 和 另一种形式的先决条件检查——你可能会重复你的先决条件。

使用合同检查,您将迫使客户使用.NET framwork 4.0或更高版本-就性能而言,虽然我无法想象这是一个问题,但最好在以某种方式做出决定之前对其进行测试。

在代码合同中 documentation ,这里有一节关于如何在运行时使用代码契约。最好提前决定如何在运行时使用代码契约,然后按照文档中的指导原则继续。

如果您不打算在发布版本中使用运行时检查器,那么最好编写遗留的“if…then throw”前提条件,而不是代码契约前提条件。您仍然可以在调试构建中编写后置条件和不变量,但它们不会在运行时被检查。但是,它们在调试构建中仍然有用,用于启用代码协定的调试目的。

在许多情况下,如果您希望从异常中恢复,则需要有关导致异常的原因的详细信息—这通常涉及创建自己的异常类并将详细信息作为属性来证明。要使用最基本的示例, ArgumentOutOfRangeException 包含属性 ActualValue ,您可以根据所得到的值读取并决定要做什么。

当你使用合同时,如果你的合同失败了,你只会得到一个基本的 ContractException ,它是由编译器生成的,并且只包含字符串形式的契约失败的详细信息,为了从中提取您想要的内容,可能需要进行一些复杂的解析—您通常不会为此费心。

如果您使用自己的异常,那么在运行时就没有理由将合同保留在那里,因为如果它们即将失败,就永远无法联系到它们——您只会白白浪费指令。

在异常检查的同时使用静态契约检查是消除错误的最有效的方式。大多数情况下,不会抛出异常,因为在运行应用程序之前,会告诉您如何解决问题。