When you are using new tools that make also something at
code level then it is good idea to check out what additions are made to
code during compilation.
Code contracts have simple syntax when we are writing
code at Visual Studio but what happens after compilation? Are our methods same as they look in
code or are they different after compilation? In this posting I will show you how
code contracts look after compiling. In my previous examples about
code contracts I used randomizer class with method called GetRandomFromRangeContracted. public int GetRandomFromRangeContracted(int min, int max) { Contract.Requires<ArgumentOutOfRangeException>( min < max, "Min must be less than max" ); Contract.Ensures( Contract.Result<int>() >= min && Contract.Result<int>() <= max, "Return value is out
of range" ); return _generator.Next(min, max); } Okay, it is nice to dream about similar
code when we open our assembly with Reflector and disassemble it. But… this time we have something interesting. While reading this
code don’t feel uncomfortable about the names
of variables. This is disassembled
code. .NET Framework internally allows these names. It is our compilators that doesn’t accept them when we are building our
code. public int GetRandomFromRangeContracted(int min, int max) { int Contract.Old(min); int Contract.Old(max); if (__ContractsRuntime.insideContractEvaluation <= 4) { try { __ContractsRuntime.insideContractEvaluation++; __ContractsRuntime.Requires<ArgumentOutOfRangeException>( min < max, "Min must be less than max", "min < max"); } finally { __ContractsRuntime.insideContractEvaluation--; } } try { Contract.Old(min) = min; } catch (Exception exception1) { if (exception1 == null) { throw; } } try { Contract.Old(max) = max; catch (Exception exception2) { if (exception2 == null) { throw; } } int CS$1$0000 = this._generator.Next(min, max); int Contract.Result<int>() = CS$1$0000; if (__ContractsRuntime.insideContractEvaluation <= 4) { try { __ContractsRuntime.insideContractEvaluation++; __ContractsRuntime.Ensures( (Contract.Result<int>() >= Contract.Old(min)) && (Contract.Result<int>() <= Contract.Old(max)), "Return value is out
of range", "Contract.Result<int>() >= min && Contract.Result<int>() <= max"); } finally { __ContractsRuntime.insideContractEvaluation--; } } return Contract.Result<int>(); } As we can see then contracts are not simply if-then-else checks and exceptions throwing. We can see that there is counter that is incremented before checks and decremented after these whatever the result
of check was. One thing that is annoying for me are null checks for exception1 and exception2. Is there really some situation possible when null is thrown instead
of some instance that is Exception or that inherits from exception? Conclusion
Code contracts are more complex mechanism that it seems when we look at it on our
code level. Internally there are done more things than we know. I don’t say it is wrong, it is just good to know how our
code looks after compiling. Looking at this example it is sure we need also performance tests for contracted
code to see how heavy is their impact to system performance when we run
code that makes heavy use
of code contracts.
