Thoughts from the Wet Coast
The musings of an ASP.NET Developer from Canada's We(s)t Coast

As part of this series on DNN Development Tips, I hope to “uncover” little know classes/methods - in the DNN Framework (and any of the 3rd party libraries that we use, such as Telerik or the .NET framework itself).

In this post, we look at two new helper modules in the Dotnetnuke.Common namespace – Requires and Guard.

What do these helper classes do?

In short they provide wrappers around typical defensive coding practices, that make the code more concise and more importantly more readable.

Lets look at a theoretical example.

   1:  public virtual IWidget CreateWidget(string widgettype)

   2:  {

   3:      //Make sure that the string passed in is not null

   4:      if (string.IsNullorEmpty(widgettype)) 

   5:      {

   6:          throw new ArgumentWxception("argument is null", widgettype);

   7:      }

   8:   

   9:      IWidget widget = Widgetfactory.CreateWidget(widgettype);

  10:      

  11:      //Make sure that the Widget returned is not null

  12:      if (widget == null)

  13:      {

  14:          throw new InvalidOperationException("widget factory returned a null widget");

  15:      }

  16:   

  17:      return widget;

  18:  }

In this example we have a method that creates a widget when given a widget type.

The method first checks if the widget type passed in is not null or empty, and throws if it is.  in line 9 the widget is created by calling a factory method which (presumably) creates the appropriate type of widget depending on the string passed.

Finally before returning the widget, a check is made to ensure that the widget is not null.

This method is quite readable but it is 18 lines long. the guts of the method is in one line (line 9) – the rest is defensive coding.  important defensive coding – but typical boiler-plate code that we should find ourselves writing repeatedly.

Lets rewrite this method using the new classes.

   1:  public virtual IWidget CreateWidget(string widgettype)

   2:  {

   3:      Requires.NotNullorEmpty("widgettype", widgettype);

   4:   

   5:      IWidget widget = WidgetFactory.CreateWidget(widgettype);

   6:   

   7:      Guard.Against(widget == null, "widget factory returned a null widget");

   8:   

   9:      return widget;

  10:  }

While the requires and guard classes both provide helper methods that, in theory, accomplish similar tasks, we have two classes as this makes the code more readable.

The requires class provides methods that enforce certain conditions that are “required” for the method to execute successfully.  so the first line “requires” that the parameter passed is not null or empty.  the guard class provides a single method against which takes a boolean as a parameter, which we can use to “guard against” (defend) a particular exception-case condition.

We could have written line 3 as:

    Guard.Against(string.IsNullorEmpty(widgettype), "widgettype was a null (or empty) string");

or line 7 as:

    Requires.NotNull("widget", widget);

but the code would be less readable.

By providing two approaches to writing defensive coding we can make the code much more readable in context, and therefore easier to maintain.

Over time we will enhance these classes with additional methods which encapsulate defensive coding practices into a more readable fluent format.