c# - 在发布版本中使用 System.Diagnostics.Contract

Question

我之前在 StackOverflow 上看到一个线程对此进行了一些讨论，但是我找不到了!

我很想知道 System.Diagnostics.Contract 类是否应该用于“真实代码”，即生产代码的发布版本？我问这个，因为根据命名空间描述，合约似乎旨在调试或分析目的。

它似乎是一个有用的库，其中功能的前置/后置条件很重要，并且可以避免编写大量 if/then/else 检查的一些工作，所以如果是这种情况，是否有替代方案核心库？

Answer 1

documentation 的第 5.1 节(参数验证和契约(Contract))详细介绍了您可能会考虑使用合约的三种主要使用模式:

1. 仅在调试版本中通过契约验证参数，在发布版本中不这样做。
2. 还在发布版本中进行验证。
3. 发布版本中的自定义参数验证，仅调试版本中的契约(Contract)。

因此至少有一种使用模式，您可以在发布版本中使用合约，至少就官方文档而言是这样。

引用:

Before you start using contracts in your own code, you need to make a few decisions that influence what contract forms to use for argument validation and where (see Figure 2). Note that you can make these decisions independently for each managed assembly you produce (each project):

The easiest use of the contract tools is if you decide that you don't need to perform argument validation at runtime in release builds (Usage 1). In that case, you use the contract tools during development, but not on the shipped bits. Remember, you can ship a contract reference assembly along with your release bits so clients can get runtime checking of your parameter validations on their debug builds via call-site requires checking.

The second easiest approach if you need argument validation in your release build is to turn on contract checking in all builds (Usage 2). You therefore take advantage of the tools to produce the runtime strings of your conditions and to perform contract inheritance for you. You can choose to produce specific exceptions for your parameter validations, or have the default ContractException. The risk of using the contract tools in your release build is that you depend on tools that have not reached production quality level.

The trickiest combination is when you want argument validation in release builds, but you are using the contract tool for runtime checking only in debug builds, but not in the release build (Usage 3). In that case, you have to continue writing your argument validation the way you already do, namely using if-then-throw statements (we call them legacy-requires). If you want these to be tool discoverable, add other contracts (such as Ensures) after them, or use Contract.EndContractBlock(), if no other contracts are present. Note that since you are not using the runtime checking tools in the release build, you are not going to get any inheritance of contracts and you have to manually repeat your legacy-requires on overrides and interface implementations. For interface and abstract methods, you still get the most benet if you write contract classes with normal requires and ensures forms so you get checking in your debug builds and they appear in contract reference assemblies and are thus visible to dependent projects and to static checkers.

这也暗示了仅使用框架其他部分的替代方案是什么:使用 if-then-throw 的常用方法。