{"id":315,"date":"2009-03-16T07:44:54","date_gmt":"2009-03-16T06:44:54","guid":{"rendered":"http:\/\/www.leading-edge-dev.de\/?p=315"},"modified":"2010-07-10T16:21:06","modified_gmt":"2010-07-10T15:21:06","slug":"code-contracts-contract-checking","status":"publish","type":"post","link":"https:\/\/www.minddriven.de\/index.php\/technology\/dot-net\/code-contracts-contract-checking","title":{"rendered":"Code Contracts #3: Contract checking"},"content":{"rendered":"

In my first two posts of this series, I covered some basic information<\/a> about Code Contracts, their origins and core elements of DbC as well as the basic declarative nature of Code Contracts, the Contract Rewriter<\/a> and why contracts are defined imperatively and not via attributation or additional keywords. In this blog post, I’ll dig even deeper to show the two main elements, how contracts on your code are checked…<\/p>\n

The functionality of checking contracts\/conditions on your code comes from two main components of Code Contracts: the dynamic checker<\/em> (runtime checker) and the static checker<\/em>. Those can be configured and activated after installation of the Code Contracts package through a new tab inside the project’s Properties window:<\/p>\n

\"Configuring<\/a>More information on that can be found e.g. on the Code Contracts User Manual<\/a>.<\/p>\n

The dynamic checker<\/h3>\n

The first component is the dynamic checker<\/em>, which is even called runtime checker, what better implies its behavior. This type of contract checking is done at runtime of your program code. Everytime when the program execution hits a point, where contracts are defined, the Contracts runtime checks, if the contracts are fulfilled in the current context, that means with the current class state, current variable and parameter values etc. Thus the dynamic checker is searching for actual<\/em> broken contracts in just the current context. Its behavior is very similar to a test (under the given context) resp. to a Debug.Assert()<\/code>, leading to the term of validation<\/em> of your code. If a contract check fails, then the default behavior is that a ContractException<\/code> is thrown and the application terminates. This can be easily adopted to your own needs.<\/p>\n

The static checker<\/h3>\n

So, dynamic checking ensures at runtime that no contracts are broken by current calls of your code. But it leads to the same problems as in unit testing: code coverage, choice of input\/output pairs etc. Perhaps contract violations are not found during testing, because the checking with a chosen set of parameters fulfills those contracts. Problems occur, when you deliver your code and other developers use parameters that you didn’t consider and then contracts are not fulfilled any more.<\/p>\n

The second and more interesting part of Code Contracts checking is the static checker<\/em>. What’s the difference to dynamic checking? The static checker is able to check defined contracts at compile time<\/em> of your code. Moreover, the static checker doesn’t only search for actual broken contracts, but for all possibilities<\/em> where contracts could be broken by the defined code. For example, let’s imagine a method int Predecessor(int x)<\/code>, that returns the value x-1<\/code> and a post-condition on that method, that the return value is in every case \">= 0<\/code>\"<\/code>. With dynamic<\/em> checking, perhaps you input some arguments for x: 1,5,100,13, … it would never lead to a situation, where the contract is broken. With static<\/em> checking instead, the static checker would analyze the code at compile time and would recognize, that there are situations (every value for x < 1<\/code>) where the post-condition of the method is not fulfilled. In this case, the static checker would output a warning to inform the developer of the possible contract breach.<\/p>\n

With all this, the static checker is doing a formal verification<\/em><\/a> of the defined contracts in contrast to the test-based validation of the dynamic checker. This is done by a complex algorithm that’s based on methods of formal logic and program verification and that’s why the static checker needs some time to perform the verification. The concrete algorithm is using abstract interpretation<\/a> of the code, thus the code is being inspected, but not executed! By this process and with a basic rule-set on the CLR, facts about the code are generated and those facts are used to find out, if the code fulfills the defined contracts or not. The behavior of Code Contracts is very nice in comparison with the dynamic checking, but the complexity of this process may not be underestimated. Moreover, it’s heavily requiring contracts on most code pieces that you use in your contracted code, for example in the .NET framework. That’s why the Code Contracts team is currently working hard to introduce contracts all over the .NET libraries. Let’s do an example: if you have a string s<\/code> and call s.Contains()<\/code>, then you as programmer know that s.Contains()<\/code> doesn’t change s<\/code> or any other values. But if there would be no contracts on String.Contains()<\/code>, then the static checker of Code Contracts could not know that Contains()<\/code> is free of side effects and isn’t changing the value of s<\/code>. Thus, it would warn on any post-condition of a method, that makes use of the value of s<\/code>.<\/p>\n

The following example shows a compiler warning, created by the static checker. The method WithDraw()<\/code> for withdrawing money from an account has been understood and implemented as deposit (using the Deposit()<\/code> method) with a negative amount<\/code>. The static checker fails, because on deposit only positive values are allowed and that’s what the pre-condition on Deposit()<\/code> declares. The warning is shown in the following picture. Furthermore you can see, that Code Contracts is suggesting a pre-condition on WithDraw()<\/code>, by which the contract could be fulfilled.<\/p>\n

\"Warning<\/p>\n

And that’s it again for the moment. In this blog post I’ve introduced the two core checking components of Code Contracts: the static checker and the dynamic checker. Where the dynamic checker is just doing a validation<\/em> at runtime under the actual values context, the static checker is performing a complex formal verification<\/em> at compile time, which finds all possible contract breaches. Those are two very different approaches and should be clear before using Code Contracts. Next blog posts will give you more examples on defining contracts and further insights.<\/p>\n

\"kick<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

In my first two posts of this series, I covered some basic information about Code Contracts, their origins and core elements of DbC as well as the basic declarative nature of Code Contracts, the Contract Rewriter and why contracts are defined imperatively and not via attributation or additional keywords. In this blog post, I’ll dig … Code Contracts #3: Contract checking<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,126],"tags":[319,129,142,128,143,135],"class_list":["post-315","post","type-post","status-publish","format-standard","hentry","category-dot-net","category-code-contracts","tag-code-contracts","tag-dynamic-checker","tag-runtime-checker","tag-static-checker","tag-validation","tag-verification"],"_links":{"self":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/315","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/comments?post=315"}],"version-history":[{"count":14,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/315\/revisions"}],"predecessor-version":[{"id":957,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/315\/revisions\/957"}],"wp:attachment":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/media?parent=315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/categories?post=315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/tags?post=315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}