16

I am referencing this answer (emphasis mine):

Have a look at the ContractClass and ContractClassFor attributes. This allows you to write classes with the code contracts in separate assemblies. This allows you to have the contracts available for dev work, doesn't clutter your code and also means you don't have to deploy the contracts with the live code

  1. Why would you not want the contracts deployed?

  2. Are contracts, from a best-practices point-of-view, strictly for development and quality control?

Community
  • 1
  • 1
  • 1
    This is a really good pair of questions here. I've asked myself recently the same sort of question. – itsmatt Mar 04 '12 at 19:05

1 Answers1

3

  1. You generally don't want to deploy postcondition contracts on release builds. This is to make sure that you don't confront people using your assemblies with errors that are your responsibility. I'm sure there are other reasons, but this is the first one that pops to my mind.

  2. Currently, there is no single best-practices point-of-view that I know of regarding Code Contracts. There are different ways to use Code Contracts ( which are described in the Code Contracts User Manual ), and each one has it's own specific guidelines.

The answer you're referencing is also not completely correct, as I've stated in the comments.

koenmetsu
  • 1,044
  • 9
  • 31
  • 6
    Let me get this straight. You do not want to confront people that use your assemblies or end-users of an application with errors that are their or your responsibility? So the solution is to just switch the contracts off and let errors ripple through the whole system and possibly making underlying data corrupt? Scary! Personally I would leave the full contracts on in the first couple of months after release, and maybe later on disable the less important contracts if performance is an issue. Hiding problems with the code is not making them go away. – rvdginste Mar 01 '11 at 15:50
  • Your code should handle 'problems' gracefully and if possible, revert to a valid state. I find that throwing a ContractException to the users of your app or api is not handling problems gracefully. Preconditions that are not met can throw a more meaningful exception (eg ArgumentNullException) with Contract.Requires(). – koenmetsu Mar 02 '11 at 08:42
  • 2
    I see your point, but my opinion is that in that case, it is not a precondition. If you get a ContractException, then the developer made a mistake. If there are problems that should be handled gracefully, then those are simply exceptional cases, and you should use normal exceptions for those. Those exceptional cases are considered "in-spec". Contract violations are considered out-of-spec. But well, that's my opinion of course. – rvdginste Mar 02 '11 at 11:01
  • 2
    Please see http://devjourney.com/blog/code-contracts-part-6-runtime-support/ , this describes in detail when you'd want to enable contracts in Release builds, and what kind of contracts to enable. – koenmetsu Mar 03 '11 at 09:24
  • @koenmetsu - your link appears to be dead - only [part 1](http://devjourney.com/blog/2014/02/12/code-contracts-part-1-introduction/) seems to be available on devjourney.com any more. – Wai Ha Lee Apr 27 '15 at 08:00
  • 1
    @WaiHaLee You're right, fortunately the wayback machine still has a reference to it :) https://web.archive.org/web/20110504123425/http://devjourney.com/blog/code-contracts-part-6-runtime-support/ – koenmetsu May 04 '15 at 09:01