Click here to Skip to main content
13,357,514 members (71,463 online)
Click here to Skip to main content
Add your own
alternative version


84 bookmarked
Posted 16 Jul 2008


, 23 Jun 2011
Rate this:
Please Sign up or sign in to vote.
A pre- and postcondition validation framework based on .NET 3.5 extension methods


CuttingEdge.Conditions is a library that helps developers to write pre- and postcondition validations in their C# 3.0 and VB.NET 9 code base. Writing these validations is easy and it improves the readability and maintainability of code.


CuttingEdge.Conditions is language independent and can be used with both C# 3.0 and VB9. The library can be run on machines that do not have .NET 3.5 installed. While the CuttingEdge.Conditions.dll assembly itself has a dependency on System.Core (.NET 3.5), users can safely add it to their .NET 2.0 projects (as long as the C# 3.0 or VB9 compilers are used).


Writing precondition validations raises the quality of code. Code with validations is easier to understand and allows developers to find bugs faster, mostly during development instead of during debugging. Writing precondition validations however has always been the poor relation in programming. It takes time to write it and many developers I worked with (even the ones I respect) skipped writing them.

Skipping precondition validations will lead to code that is more difficult to use and is likely to be misused. It allows developers to pass invalid method arguments, which results in unexpected program behavior and those awful NullReferenceExceptions from deep down the call stack. It leads to a higher amount of bugs and thus more time spent debugging.

The CuttingEdge.Conditions library is an attempt to lower the barrier of writing precondition validations and make code more readable, thus resulting in better code, less bugs, and shorter development cycles.

To understand how CuttingEdge.Conditions tries to achieve this, let us first have a look at some code we might write on a daily basis. Here is an C# example of precondition validations, the old fashioned way:

void TheOldFashionWay(int id, IEnumerable<int> collection, DayOfWeek day)
    if (id < 1)
        throw new ArgumentOutOfRangeException("id", String.Format(
            "id should be greater than 0. The actual value is {0}.", id));
    if (collection == null)
        throw new ArgumentNullException("collection", 
            "collection should not be empty");
    if (collection.Count() == 0)
        throw new ArgumentException("collection should not be empty", 
    if (day >= DayOfWeek.Monday && day <= DayOfWeek.Friday)
        throw new InvalidEnumArgumentException(String.Format(
            "day should be between Monday and Friday. " +
            "The actual value is {0}.", day));

    // Do method work

That’s an awful amount of code for a few simple validations! Here’s how it looks if CuttingEdge.Conditions would be adopted:

void TheConditionsWay(int id, IEnumerable<int> collection, DayOfWeek day)
    Condition.Requires(id, "id").IsGreaterThan(0);
    Condition.Requires(collection, "collection").IsNotEmpty();
    Condition.Requires(day, "day").IsInRange(DayOfWeek.Monday, DayOfWeek.Friday);

    // Do method work

That’s quite different, isn't it? It’s not only far less code; it’s also very readable. And please note that both methods have exactly the same contract. Both methods throw exactly the same exceptions and exception messages!

Besides these normal precondition checks, CuttingEdge.Conditions enables you to do postcondition checks as well. Unlike a precondition, the violation of a postcondition has purely an internal cause. It can be considered a bug. Throwing an ArgumentException in that case would clearly confuse the developer using that code. Because of this difference, CuttingEdge.Conditions will always throw a PostconditionException on a violation of a postcondition.

Here is an example of a postcondition check:

public ICollection PostconditionExample()
    object obj = Activator.CreateInstance(typeof(Collection<int>));

    Condition.Ensures(obj, "obj").IsNotNull().IsOfType(typeof(ICollection));

    return (ICollection)obj;

The postcondition example shows two interesting things. Firstly, The Ensures extension method is used to start a postcondition validation. Secondly, method calls can be chained in a fluent manner as shown with the IsNotNull and IsOfType methods.


The CuttingEdge.Conditions API has many validation methods that easily cover 99% of your validation needs. There are currently 412 extension methods for 53 different checks. The API can be divided in eight groups: 

  • Entry point methods
  • Null check methods
  • Type check methods
  • Comparison checks
  • Collection checks
  • String checks
  • Numeric checks
  • Evaluations

The number of methods will possibly grow over time, and please comment here, on my blog or on CodePlex if you think there are validations missing. I will consider adding them to the library. Also note that it’s easy for you to extend the API with your own methods, by simply placing extension methods in your own project. For more information on extending CuttingEdge.Conditions, please read the Extending CuttingEdge.Conditions wiki on CodePlex.

More Information

This third stable release of the CuttingEdge.Conditions library has just been released. You can download the source and runtime library from CodePlex. Please visit or my blog.

Happy validating!


This article, along with any associated source code and files, is licensed under The MIT License


About the Author

The .NET Junkie
Software Developer (Senior)
Netherlands Netherlands
I'm a freelance developer from the Netherlands, working with .NET technology on a daily basis, and officially diagnosed as a workaholic.

You may also be interested in...

Comments and Discussions

AnswerRe: Extension methods on .net2.0 Pin
The .NET Junkie18-Jul-08 9:07
memberThe .NET Junkie18-Jul-08 9:07 
GeneralRe: Extension methods on .net2.0 Pin
geo_m21-Jul-08 1:27
membergeo_m21-Jul-08 1:27 
GeneralRe: Extension methods on .net2.0 Pin
Qwertie6-Aug-08 12:04
memberQwertie6-Aug-08 12:04 
GeneralRe: Extension methods on .net2.0 Pin
The .NET Junkie13-Aug-09 3:33
memberThe .NET Junkie13-Aug-09 3:33 
GeneralGood. Here's an idea for improvement. Pin
Judah Himango16-Jul-08 18:01
memberJudah Himango16-Jul-08 18:01 
GeneralRe: Good. Here's an idea for improvement. Pin
The .NET Junkie17-Jul-08 3:07
memberThe .NET Junkie17-Jul-08 3:07 
GeneralRe: Good. Here's an idea for improvement. Pin
Judah Himango17-Jul-08 7:13
memberJudah Himango17-Jul-08 7:13 
GeneralRe: Good. Here's an idea for improvement. Pin
The .NET Junkie17-Jul-08 8:51
memberThe .NET Junkie17-Jul-08 8:51 
Hi Judah,

Like I described, I don't really like Requires(() => id). It just doesn't read as well as Requires("id") and it doesn’t perform well either.

Funny you mention the Microsoft.Contracts namespace.
I am aware of it's existence within the System.Core.dll. I believe that this namespace is primarily used by the Spec# language. As a matter of fact, CuttingEdge.Conditions is inspired by Spec# (you can read that here)!

In my opinion, design by contract (DbC) is the way to go for our software community (and DbC is a much better solution than my library, because it's based on compiler support, which my library lacks, of course). But Spec# is currently a research project and it will probably not be released in the near future. We also shouldn’t expect any validation support like that of Spec# within our mainstream C# language. That's the reason I built this framework. Once we'll have DbC! In the mean time, frameworks like mine can hopefully fill the gap.

GeneralRe: Good. Here's an idea for improvement. Pin
Judah Himango17-Jul-08 11:35
memberJudah Himango17-Jul-08 11:35 
GeneralRe: Good. Here's an idea for improvement. [modified] Pin
The .NET Junkie18-Jul-08 13:29
memberThe .NET Junkie18-Jul-08 13:29 
GeneralRe: Good. Here's an idea for improvement. Pin
Judah Himango20-Jul-08 10:49
memberJudah Himango20-Jul-08 10:49 
GeneralRe: Good. Here's an idea for improvement. Pin
The .NET Junkie20-Jul-08 11:53
memberThe .NET Junkie20-Jul-08 11:53 
GeneralRe: Good. Here's an idea for improvement. Pin
Judah Himango20-Jul-08 11:57
memberJudah Himango20-Jul-08 11:57 
GeneralRe: Good. Here's an idea for improvement. Pin
The .NET Junkie4-Aug-08 4:09
memberThe .NET Junkie4-Aug-08 4:09 
GeneralRe: Good. Here's an idea for improvement. Pin
Judah Himango29-Oct-08 12:43
memberJudah Himango29-Oct-08 12:43 
GeneralRe: Good. Here's an idea for improvement. Pin
The .NET Junkie8-Nov-08 4:41
memberThe .NET Junkie8-Nov-08 4:41 
GeneralRe: Good. Here's an idea for improvement. Pin
balazs_hideghety9-Feb-09 11:30
memberbalazs_hideghety9-Feb-09 11:30 
AnswerRe: Good. Here's an idea for improvement. Pin
Patrick Wolf19-May-09 18:37
memberPatrick Wolf19-May-09 18:37 
GeneralRe: Good. Here's an idea for improvement. Pin
The .NET Junkie19-May-09 22:54
memberThe .NET Junkie19-May-09 22:54 
AnswerRe: Good. Here's an idea for improvement. Pin
Patrick Wolf25-May-09 6:16
memberPatrick Wolf25-May-09 6:16 
GeneralRe: Good. Here's an idea for improvement. Pin
The .NET Junkie25-May-09 9:21
memberThe .NET Junkie25-May-09 9:21 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.180111.1 | Last Updated 23 Jun 2011
Article Copyright 2008 by The .NET Junkie
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid