Is there any reason not to use Run-time Contract Checking with Code Contracts?

I've recently listened to Kevin Hazzard talk about Code Contracts in .Net Rocks show 570 (http://devjourney.com/community/dotnet-rocks-show-570-with-kevin-hazzard/). He mentions enabling Run-time Contract Checking as an option some people might choose to use while others might not.

Why would you not use Run-time Contract Checking for your Code Contracts? Is there a significant negative impact on performance? Other rea开发者_开发问答sons?

If you disable this feature, how do you deal with preconditions in your methods at run-time?

In some non-mission-critical applications, you may actually want to let the errors slide in a release build rather than throwing an error dialog in the face of the user. Small bugs that the end-user may never notice can cause your contract check to fail and harm user experience.

It would seem off to me to use both Contracts and another form of precondition checking - as you'd presumably then end up duplicating your preconditions.

Using contract checking you'll be forcing clients to have .Net Framwork 4.0 or above - as far as performance is concerned, whilst I can't imagine this being a problem, you're best placed testing it out before making a decision one way or another.

In the Code Contracts documentation, there's a section about how to use Code Contracts at runtime. It's better to decide in advance on how you're going to use Code Contracts at runtime, and then proceed following the guidelines in the documentation.

If you're not going to use the Runtime Checker in release builds, you're better of writing legacy 'if...then throw' preconditions instead of Code Contracts preconditions. You can still write postconditions & invariants in your debug build, but they will not be checked at runtime. They are still useful however in your debug build, for debugging purposes with Code Contracts enabled.

In many situations, if you want to recover from an exception, you need the details on what caused it - that usually involves creating your own exception classes and proving your details as properties. To use the most basic example, an ArgumentOutOfRangeException contains a property ActualValue, which you might read off and decide what to do based on the value you get.

When using contracts, if your contract fails, you'll just be given a basic ContractException, which is compiler generated, and only contains details about the contract failure in string form, which may need some complex parsing in order to extract what you want from it - you generally wouldn't bother doing that.

If you're using your own exceptions, there should be no reason to keep the contracts in there at runtime, because they'll never be reached if they are about to fail - you'd just be wasting instructions on nothing.

Using static-contract checking alongside your own exception checking is the most effective form of eliminating errors. Most of the time, your exceptions will never be thrown because you're told how to fix the problems before running your app.