CAUBLESTONE INK

.net development and other geeky stuff

Application Helpers: Protect your method calls

Posted on January 26th, 2009


First thing, refactor, refactor, refactor. Most ideas come from refactoring of your code. It’s amazing how much you do when you start refactoring things. The big benefit of course is less code. If you have a couple hundred thousand lines of code or even ten thousand lines of code, refactoring even a small thing can cut down your code base and improve readability. This article is geared towards refactoring.

In the course of working on multiple applications over the years you find you tend to do the same things over and over again. One of those things is constantly checking objects for null, data type compatibility, etc. How many times have you written the following lines of code.

if (object == null)
{
   throw new ArgumentNullException();
}

or

if (object.GetType() == typeof(sometype))

The amount of code there justs adds up. Not only that but you probably have lots of null checks maybe even in the same method. So what if we wrote something like this instead:

Protect.IsNotNull(obj, "The object you are checking is null");

So if you had multiple objects going into an object you would have something like this:

Protect.IsNotNull(obj1, "Object 1 is null");
Protect.IsNotNull(obj2, "Object 2 is null");

Now since we are talking about refactoring what if we even refactor that code to make use of the newer features of the framework. Since the Protect methods throw an exception if the object is null in this case what if we wanted to expand it to allow for multiple checks. We could do something like this:

Protect.Against(obj1 == null, "Object 1 is null");
Protect.Against(String.IsNullOrEmpty(stringData), "The string is emtpy.");

As you can see we can now handle multiple things at the same time. So let’s look at what is under the Protect method.

public static class Protect
{
  public static void Against(bool condition, string message) where T: Exception
  {
    if (condition)
      throw new (T)Activator.CreateInstance(typeof(T), message);
  }
}

As you can see not much but it makes your code easier to read and it adds a nice bit of conformity while reducing the total lines you need to maintain and worry about. The T parameter is the type of exception you want thrown based on your condition. As long as you have a boolean condition your good. Anything that evaluates to true will throw the exception. The message will be on the exception that is thrown. Based on this pattern we can also add things like Inheritance checks, Type checks, Enum, checks, etc. It’s really easy for it to morph into what you need as you need it. You can even extend it with delegates, Func<> methods, setup for linq style syntax, etc. the sky is the limit.

Here is what it would look like in use inside of a method:

public void DoSomething(List data, Dictionary other)
{
    Protect.Against(data == null, "Data is null");
    Protect.Against(other==null, "Other is null");

    foreach (int i in data)
    {
        Console.WriteLine(other[i]);
     }
}