3

Could I start using CodeContracts instead of:

if (XXX == Y)
    throw new ArgumentException("bla bla");

How does it work if I develop a library and my library users do not use CodeContracts?

jgauffin
  • 99,844
  • 45
  • 235
  • 372

3 Answers3

2

Assuming that the code using code contracts is run through the binary rewriter, it will throw exceptions like code you posted. The re-writer goes through the code and replaces the contract code with argument checking etc. It's kinda like aspect oriented programming. It injects code to handle situations for you after you've compiled it.

If they don't use Code Contracts they will not get the benefit of having static analysis performed which is designed to look at the contract and warn them they might get an error based on the contract and their code.

Code Contracts

kemiller2002
  • 113,795
  • 27
  • 197
  • 251
  • One thing to note is that the static analysis is only available if you're using a Visual Studio 2010 package above Professional, which is very unfortunate. :( – adamjford Dec 20 '10 at 15:18
  • Yeah, that's true which is sad. Although personally, if I have to pay for it, it's worth the price. – kemiller2002 Dec 20 '10 at 15:26
1

To the point: It's possible to write statements like this

Contract.Requires<ArgumentNullException>(argumentToCheck, "argumentToCheck");

If you enable the Runtime checker in your build configuration, the rewriter will rewrite preconditions like this to an ordinary ArgumentNullException.

Callers of your code will be shown an ArgumentNullException, or whatever exception you provide, regardless of whether or not they have Code Contracts installed.

koenmetsu
  • 1,044
  • 9
  • 31
0

I have been using code contracts and for casual use, they address 2 code problems for me that didn't have nice solutions earlier:

  • checking return values checking
  • invariants appear to be a poorly named combined parameter check/entry point and return value/exit point assertion.

I could declare a temp variable for the return value and assert some things before return it, but it's extra friction.

checking parameters already had a solution: throw ArgumentException.

Code contracts adds one tiny thing to ArgumentException-- it makes you check arguments very early, which in my opinion is a good thing.

There is much more going on with Code Contracts, but I've just dipped my toe into and I don't have the edition that does super-comprehensive static checks. I plan to work my way up to using Code Contracts more completely, and once I have done so-- it will be more elegant to check parameters using the same framework instead of switching back and forth between Code Contracts and if/then/throw ArgumentException

MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
  • Just a correction about invariants; they are checked upon exit of any public method, not upon every line of code. If a public method calls any other method on the class the invariant check is disabled until the original call returns (this is also the case if the method calls a method on another class which in turn calls back into the original class - the check is only performed upon return of the *original* method). – porges Dec 20 '10 at 22:55
  • @Porges Then I don't understand what they do anymore. I've updated my answer. You comment, which I don't understand--implies to me that there isn't any interesting difference between invariants and return value checking. – MatthewMartin Dec 21 '10 at 14:56
  • It's designed so that invariants always hold from the point of view of other classes. A method *inside* the class can temporarily violate invariants as long as they are true when it returns control to the caller. – porges Dec 21 '10 at 23:37