Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Framework Gems – 1 - Requires and Guard – Two New Helper Classes

This article is cross-posted from my personal blog.

In this new blog series of short posts I will “uncover” little know classes/methods - “gems” - in the DotNetNuke Framework (and any of the 3rd party libraries that we use, such as Telerik or the .NET Framework itself).

In this first post, we look at two new helper modules in the DotNetNuke.Common namespace.  A Visual Basic Module is equivalent to a C# static class (ie a class where all the members are static).

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.

Figure 1: An example of a method with typical defensive coding

   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 ArgumentException("Argument is null", widgetType);
   7:      }
   9:      IWidget widget = WidgetFactory.CreateWidget(widgetType);
  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:      }
  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.

Figure 2: The method rewritten using Requires and Guard helper classes

   1:  public virtual IWidget Createwidget(string widgetType)
   2:  {
   3:      Requires.NotNullOrEmpty("widgetType", widgetType);
   5:      IWidget widget = WidgetFactory.CreateWidget(widgetType);
   7:      Guard.Against(widget == null, "Widget Factory returned a null widget");
   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 the code is 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.


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (22)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (270)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?