Defensive Programming (Spec#, DotNet)

Do you apply Defensive Progamming techniques?

Based on my experience, changes are good that you are not.
If so you may be missing out on many benefits such as:

• Producing easier to use, understand, and maintain class-libraries;
• Havinging applications that are much easier to support and test;
• And last but not least, having more secure code.
  

In other words: defensive programming makes your solutions more easy from many viewpoints. Which, to me, in itself is a goal.


So what is this defensing technique about?

Defensing is a concept that has many aspects to it (see WikiPedia here) but in this article I will focus on the ensuring that the so called "pre-conditions" are met instead of assuming they will be met.

I am sure you know what I am talking about we have to deal with this every day all of the time! Just think about all those function parameters that might have an invalid value when that function is being called. That integer parameter* that should not be zero or negative or that object-reference parameter that just should not be null for example. With defensing you always check those pre-conditions first and immediately throw an exception if one of them is not met.

In any application there are thousands of those "pre-conditions" that could and should be checked. Sure that sounds like lot but in fact when you do it from the start it is hardly any extra work and you start enjoying the benefits almost immediately returns your small investment . And with the help of a small (existing) library the equation is even more interesting! Let me explain what I mean:

• For anybody, including yourself after a while, maintaining your code it is immediately crystal clear what your function cannot do or handle! In many cases there is no need to test if this new situation is supported, anymore;

• If one of your methods is called with an invalid value a clear exception is thrown immediately. No more “Null Reference Exceptions”, for example, deeper in your library that are all too hard to trace! Which is only possible by developers nothing to do for the support department, over and over again.

• Many security issues originate from an unforeseen use of an application or library. By making sure that all your, assumed ,preconditions are checked it becomes much less likely to have your methods begin misused.

Should I really use this? It sound like a lot of work!

Sure it sounds like it, but when you do this right this is certainly one of those so called "Low Hanging Fruits". Quick wins with huge benefits. If you would ask me just do it! Apply from the start of a new project or add when changing a function that already exists. A good programmer is a lazy programmer so make defensing more easy for yourself using Macro's, Tooling and a small library of perhaps extention methods!?


Oke, I am convinced! What do I need to do to start defensing, Today?

One of the first things we need to do is have a library that helps us easily check parameter values and throw the appropriate clear exceptions. You basically have three options here:

• One option is of course to write your own; This has the benefit that the exceptions that you fully control the messages and types of exceptions that are thrown;

• Another option is to use the assertion classes from any Unit Tests framework. The, architectural, downside to this is that you are using Unit Test classes and libraries in a production environment. Conceptually this is not wrong but as far as I know there are no practical downsides.

• The last, certainly not the least, option is to use the upcoming, but already available, Spec# framework from the Microsoft Research department. Which has the huge benefit of having a framework specifically for this use on one side which comes with integrated Visual Studio support as well!

Spec# sounds really interesting! Where can I find more?

I will soon write an introductionairy article about this, so stay tuned!


How do you look at Defensing from an architectural point of view?

Architecture is about how things relate and about meeting stakeholder stakes:

• The library classes that help to make your defensing easy should be part of your Core;

• The information about the valid and invalid use of your methods should be part of your technical (generated) documentation. This is something, spec# nor sandcastle or nDoc, does not yet take into account but possibly could.

• Defensing makes your class-libraries more easy to use, to maintain, to support and more secure. This is someting that should be in the interest of every stakeholder but in particular to the CTO and ICT (support)Managers.

We have been talking about defensing, but can’t I just see what it looks like?

Sure thing! To wrap things up I have included some examples below using my own practical little defensing framework. After all, we should not talk too much about coding, coding is something that you “just” should do!

public void example1(object parameter)

{
Defence.Object.MustNotBeNull(parameter);
…
}

protected void example2(object valueToAdd)
{
Defence.Boolean.ShouldBeFalse(_collection.IsReadOnly );
…
}

Does not look difficult does it? I told you so! The best things in live are the simple things...

Happy Defensing!

----

*) I know we might use an Unsigned Integer here, but this is not CLS-Complient thus in many not recommended to be used.