有什么理由不使用代码契约的运行时契约检查吗？
我最近听 Kevin Hazzard 在 .Net Rocks show 570 (http://devjourney.com/community/dotnet-rocks-show-570-with-kevin-hazzard/）。他提到启用运行时契约检查作为一种选项，有些人可能会选择使用，而另一些人则可能不会。
为什么你不使用运行时契约检查来检查你的代码契约？对性能有显着的负面影响吗？其他原因？
如果禁用此功能，如何在运行时处理方法中的前提条件？
I've recently listened to Kevin Hazzard talk about Code Contracts in .Net Rocks show 570 (http://devjourney.com/community/dotnet-rocks-show-570-with-kevin-hazzard/). He mentions enabling Run-time Contract Checking as an option some people might choose to use while others might not.
Why would you not use Run-time Contract Checking for your Code Contracts? Is there a significant negative impact on performance? Other reasons?
If you disable this feature, how do you deal with preconditions in your methods at run-time?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在某些非关键任务应用程序中，您实际上可能希望让错误在发布版本中滑动，而不是在用户面前抛出错误对话框。最终用户可能永远不会注意到的小错误可能会导致合同检查失败并损害用户体验。
In some non-mission-critical applications, you may actually want to let the errors slide in a release build rather than throwing an error dialog in the face of the user. Small bugs that the end-user may never notice can cause your contract check to fail and harm user experience.
在我看来，同时使用契约和另一种形式的前提条件检查 - 因为你可能最终会重复你的前提条件。
使用合同检查，您将迫使客户拥有 .Net Framwork 4.0 或更高版本 - 就性能而言，虽然我无法想象这是一个问题，但您最好在做出决定之前对其进行测试或另一个。
It would seem off to me to use both Contracts and another form of precondition checking - as you'd presumably then end up duplicating your preconditions.
Using contract checking you'll be forcing clients to have .Net Framwork 4.0 or above - as far as performance is concerned, whilst I can't imagine this being a problem, you're best placed testing it out before making a decision one way or another.
在代码合同文档中，有一节介绍了如何在运行时使用代码契约。最好提前决定如何在运行时使用代码契约，然后按照文档中的指南进行操作。
如果您不打算在发布版本中使用运行时检查器，那么最好编写遗留的“if...then throw”前提条件，而不是代码契约前提条件。您仍然可以编写后置条件 &调试版本中存在不变量，但不会在运行时检查它们。然而，它们在调试构建中仍然有用，可以在启用代码契约的情况下进行调试。
In the Code Contracts documentation, there's a section about how to use Code Contracts at runtime. It's better to decide in advance on how you're going to use Code Contracts at runtime, and then proceed following the guidelines in the documentation.
If you're not going to use the Runtime Checker in release builds, you're better of writing legacy 'if...then throw' preconditions instead of Code Contracts preconditions. You can still write postconditions & invariants in your debug build, but they will not be checked at runtime. They are still useful however in your debug build, for debugging purposes with Code Contracts enabled.
在许多情况下，如果您想从异常中恢复，则需要导致异常的详细信息 - 这通常涉及创建您自己的异常类并将详细信息证明为属性。使用最基本的示例，
ArgumentOutOfRangeException包含一个属性ActualValue，您可以读取该属性并根据获得的值决定要执行的操作。使用合约时，如果你的合约失败，你只会得到一个基本的ContractException，它是编译器生成的，并且只包含字符串形式的合约失败的详细信息，这可能需要一些复杂的解析为了从中提取你想要的东西 - 你通常不会费心这样做。
如果您使用自己的异常，则没有理由在运行时将合约保留在那里，因为如果它们即将失败，则永远不会到达它们 - 您只是在浪费指令。
将静态契约检查与您自己的异常检查一起使用是消除错误的最有效形式。大多数时候，您的异常永远不会被抛出，因为您在运行应用程序之前被告知如何解决问题。
In many situations, if you want to recover from an exception, you need the details on what caused it - that usually involves creating your own exception classes and proving your details as properties. To use the most basic example, an
ArgumentOutOfRangeExceptioncontains a propertyActualValue, which you might read off and decide what to do based on the value you get.When using contracts, if your contract fails, you'll just be given a basic
ContractException, which is compiler generated, and only contains details about the contract failure in string form, which may need some complex parsing in order to extract what you want from it - you generally wouldn't bother doing that.If you're using your own exceptions, there should be no reason to keep the contracts in there at runtime, because they'll never be reached if they are about to fail - you'd just be wasting instructions on nothing.
Using static-contract checking alongside your own exception checking is the most effective form of eliminating errors. Most of the time, your exceptions will never be thrown because you're told how to fix the problems before running your app.