I must say this is good article, but be aware that some things can and will some times put you on wrong way.

I’m currently working on VS2008 Tool which will do static and dynamic analyze of code. But I’m just at start because its working with IL code and there is lots of work to do. In min time I’m googleing if someone has done it already for .NET :) so I can be focused on my projects full time :)

One more thing, DBC is not test driven design, it is mathematical prove that your application is working correctly.

Regards,
Milan

I’ve just extended this to check that arguments are not null.

Here is the method

———————————-
public static void RequireArgumentNotNull( this object obj, Expression<Func> expr )
{
var x = expr.Compile();
var o = x();

if( o == null )
{
string paramName = “”;

if( expr.Body is MemberExpression )
{
paramName = ((MemberExpression)expr.Body).Member.Name;
}

throw new ContractException( expr.ToString(), new ArgumentNullException( paramName ) );
}
}
———————————-

And an example of its usage

———————————-
public void TestArg( string someArg )
{
this.RequireArgumentNotNull( someArg );

…
}
———————————-

The great thing about this is that the param name is now not a string as it used to be with a simple “throw new ArgumentNullException(…)”, so refactorings work etc. Naturally you need to rely on the user using the method correctly but since in this case I’m my only user its not a problem :)

Andre

Yes, that would be nicer. I guess that with closures I don’t need to worry too much about whether the objects I want to make comparisons on are in scope within the lambda when it gets invoked inside the predicate checking method. I guess that parameter stemmed from earlier incarnations, but it’s really not needed any more.

Cheers

Andrew

this.Require(() => !string.IsNullOrEmpty(location));

At least that way the reader isn’t looking around thinking, “Ok, there’s this parameter x . . . what’s it for?”

Thanks for your kind remarks - glad to know you (too) are getting something out of this! ;-)

Yes, In this case the syntax of any predicate will be of the form:

static void Assert(bool testresult){if(!test) throw new Exception();}

but there is an implied semantic difference, which is why I’ve distinguished between the two (needlessly). A Require-type method is equivalent to any other ‘Assert’ type method - it checks the incoming boolean, and if false it throws. The Ensure, on the other hand could do a more complicated job, because it it not only testing the current state, but comparing it to the previous state.

In addition, the Ensure could throw a different contract exception like EnsureException or something like that. I’ve done this before to distinguish the type of predicate I was testing. I haven’t done it with this little system, but I probably should. That would be easier to implement if I had two predicate testing methods: Require and Ensure.

Cheers

Andrew

Im just coming to terms with all the DBC / Spec# stuff and I had a very quick question .. does this mean that Ensure has exactly the same syntax as Require ?

Right now in my production code, I’m sort of doing a hybrid of a “Guard” class for basic contracts and Asserts for ensure clauses. I’ll be checking this blog for ideas on how to go further than that though.

I noticed the same (frustratingly internal) things too. I also enjoyed your post very much. I’m sorry I didn’t give you any link love at the time of writing - I forgot the URL between me reading your post and revisiting this issue myself.

Using a stack trace might be acceptable, except that it only tells me _where_ the exception got thrown (not why). That where part will be in the predicate method, not in the method that called the predicate, so it will not be so useful. Also being able to literally show the code (rather than its location) is really useful when you’re potentially just looking in log files. An exception class or stack trace can’t do this normally - that’s why I had to resort to LambaExpressions.

Going back to the disassembly of the System.Core assembly, it looks as though there’s a method called ‘Old’ that seems to serve the same purpose as my ‘before’ extension method. It’s not clear how or where that gets used, but it definitely requires the spec# assembly rewriter to provide those snapshot services. My ‘before’ extension method allows me to describe the effects that the method will produce if you meet the contract in the require clauses of the method. Which is critical to DBC, in ensuring that you the service provider meet the terms of the contract.

Unfortunately, one critical aspect of the DBC picture is still missing from my implementation - inheritance. In Eiffel, and attributes in .NET, you can control the inheritance of a constraint. With virtual methods, a specialisation relationship increases the total constraints as new constraints get added to the method in the sub-class. Using constraints within the body of the method denies me that ability. That’s the reason I was so set on using attributes to begin with, where the ‘GetCustomAttributes’ method will retrieve all of the attributes all the way up the inheritance hierarchy.

I see that flaw as pretty major in my implementation, but right now I can’t see a way around it. If you have any ideas, please let me know. I think DBC is a very powerful way to increase the quality of my code, and to help me think about how it works in the abstract. So I’d like to get it right.

Cheers

Andrew