System.Diagnostics.Contracts的有用性

Question

我一直在使用新的System.Diagnostics.Contracts类，因为它一开始似乎非常有用。用于检查入站参数、返回值等的静态方法。它是一个干净的接口，可以替换大量if语句和内部构建的库工具。

然而，在大多数运行时情况下，它似乎不太有用。据我所知，它不会抛出错误，所以我无法捕捉到任何信息来判断合同是否失败。它弹出一个带有错误的对话框。如果我在一个很少人工查看it...how的远程机器上运行wcf服务，我会知道合同失败了吗？如果我不能捕捉错误发生的事实，我如何才能让服务的调用者知道他们已经失败了呢？

抛接已经有一段时间了，我不明白为什么合同要绕过这个。我是不是想不正确地使用这个东西？如果是这样的话，那么有人给我一个现实的情况，运行时契约是有意义的。肯

Answer 1

据我所知，它不会抛出错误，所以我无法捕捉到任何信息来判断合同是否失败。

如果您需要抛出一个特定的异常来调用要捕获的代码，那么您应该使用Contract.Requires<TException>方法或遗留的If -然后抛出，然后是Contract.EndContractBlock()。例如，当其他代码已经期望并依赖于抛出的常规异常时，您就会这样做。

有关何时使用不同形式的前提条件的完整说明，请参阅5.1节:参数验证和用户手册合同。

它弹出一个带有错误的对话框。

如果取消项目设置的“Contracts”选项卡中的“”，则会在调试时在代码中的违规点(而不是对话框)引发实际的异常。然而，这并不是为了捕捉。

抛接已经有一段时间了，我不明白为什么合同要绕过这个。我是不是想不正确地使用这个东西？如果是这样的话，那么有人给我一个现实的情况，运行时契约是有意义的。

第7.5节: Rational for Runtime行为和第7.6节: ContractException of 用户手册解释了为什么它以这种方式工作。

其思想是，您不应该需要编写包含处理违反合同行为的特定逻辑的程序。它们不应该发生在正确的程序中，并指出代码中需要修复的严重错误。这类似于您应该如何避免捕获ArgumentNullException。

在不显示代码本身的错误的异常情况下，如找不到文件时，仍然应该抛出常规异常。这允许调用代码酌情处理这种情况。

如果我在一个很少人工查看it...how的远程机器上运行wcf服务，我会知道合同失败了吗？

最好，在将软件投入使用之前，您应该尽可能多地对其进行测试，以确保它不会违反任何合同。

如果您有特殊的需要重写运行时行为，可以通过编写您自己的契约运行时类来实现。有关更多信息，请参见第7.7节:提供用户手册的自定义合同运行时类。

编辑:作为对以下评论的回应.

您说这是为了查找代码中的错误，但是代码中的大多数错误来自外部来源传入的数据，而不是代码错误。软件需要两者兼而有之，记录某些人传递的错误数据，并告诉他们他们传递了错误的数据，这样他们才能修复它。

先决条件是定义何时允许调用方法，并在调用方法时由调用方验证的契约。运行时检查器将在调用代码中注入适当的检查，而不是方法本身。如果您有可用的静态检查器，则在调用该方法之前，当您无法确保先决条件时，它将向您指出。

在您的情况下，处理数据的内部方法应该定义先决条件，说明它们所允许的数据类型。当数据从无法控制的外部源传入时，您应该验证它并以通常的方式处理它；您不想为此使用代码契约。但是，例如，如果您忘记完全验证该数据，则在使用先决条件调用内部代码时，您将遇到违反合同的情况。这表示您自己的代码中有一个错误。