Am I correct that there's no way to turn on *only* Assumes in a release build?

Question

Further to this earlier discussion (Feature Request: Unconditional Assume and Assert) on the forum, I was wondering if there was any way, or anyone saw value in being able to rewrite only the Assumes in a release build?

My reasoning here is that everything apart from the Assumes are in theory statically verifiable, so there's less cause to re-verify a proven Requires, Ensures, Invariant or Assert at runtime. However, if the Assumes don't hold, then the proof doesn't hold, so they absolutely need runtime checks.

Answer 1

Hi,

Note that my feature request was actually a mistake because it turns out that it was already implemented and I just didn't realize it!  Applying more than one ConditionAttribute to a method is disjunctive not conjunctive, so Assume and Assert are actually conditional on either the DEBUG -or- CONTRACTS_FULL symbols, rather than requiring both.

But to answer your question, I don't think it's possible to only include assumptions.  At the very least, theoretically, if you were to disable all contracts then you would still get assumptions and assertions too if you were to define the DEBUG symbol, though I haven't tested it myself.

Including preconditions is a good thing anyway because it implements a fail-fast strategy.  Assumptions are only good when they are reached, so if an assumption will be broken because of a caller's arguments, then it's best to fail sooner rather than later.

If you could ensure that all code calling into your APIs was also built with Code Contracts enabled, then perhaps that would be a fair reason to disable all contracts except for assumptions; however, in practice this isn't possible.  For example, consider that contracts aren't checked in delegates, which are often used as callbacks from Framework code.  Since they aren't checked, it's possible that preconditions on a given method will be invalid at runtime due to the method being called from within a delegate in your own code or a callback from the FCL.

Furthermore, the static checker has bugs.  And it will always be limited to a certain extent due to the possibly infinite complexity of code and the time constraints involved during builds.  In theory, if the static checker was perfect, then I'd agree that including anything but assumptions would be redundant, but in reality I feel (IMHO) it's best to include at least preconditions and in some cases post-conditions and invariants as well, with respect to performance of course.

- Dave

---

http://davesexton.com/blog