Sitecore.Diagnostics.Assert statements

Recently I was corrected by my colleague Alan Coates about my use of Assert statements in my code, which gave me the opportunity to write this article.

Sitecore has a fundamental Assert (Sitecore.Diagnostics.Assert) namespace which differs fundamentally from the .NET Debug.Assert that it actually thows an exception if the asserted condition is false. Asserting your code is a fast way of checking that conditions are met in a function before executing it:

void Page_Load(object sender, System.EventArgs e)

private void DoStuff(Item item)
  Sitecore.Diagnostics.Assert.ArgumentNotNull(item, "item"); // Assertion

The example above throws an ArgumentNullException if the item parameter is null, and it even formats the exception message like this:

Value cannot be null.
Parameter name: item

Sitecore contains different Assert statements which thows different exceptions. In the example above I could have used the IsNotNull statement instead:

private void DoStuff(Item item)
  Sitecore.Diagnostics.Assert.IsNotNull(item, "item");

But I would then return an InvalidOperationException and the exception message would not have been formatted for me, and I would have to write the complete exception message myself:

private void DoStuff(Item item)
  Sitecore.Diagnostics.Assert.IsNotNull(item, "The parameter 'item' is null");

There are several function to choose from, each of thise returns different exceptions when the condition is not met:

  • AreEqual return an InvalidValueException. You have to write the exception message yourself (for example “a is not equal to b”)
  • ArgumentCondition, ArgumentNotNull, ArgumentNotNullOrEmpty return an ArgumentException, pre-formatted for you (see the examples above).
  • CanRunApplication return an AccessDeniedException if the user does not have access to the application stated in the parameter (this is probably mostly used internally)
  • HasAccess also returns an AccessDeniedException if the condition is not met.
  • IsEditing returns an EditingNotAllowedException if the item in the parameter is not in editing mode.
  • IsFalse, IsNotNull, IsNotNullOrEmpty, IsNull and IsTrue return an InvalidOperationException if the condition is not met. You have to format the exception message yourself.
  • ReflectionObjectCreated returns an UnknownTypeException if the condition is not met (also most an internal function I guess).
  • Required returns an RequiredObjectIsNullException when condition is not met. You have to format the message yourself.
  • ResultNotNull is basically a generic version of ArgumentNotNull returning the message “Post condition failed” when condition is not met.

if you look in the Sitecore source code you will notice that basically every Sitecore function asserts all parameters before executing the function, and so should you.

But remember the exception handling as well. Asserting parameters is good practise, but crashing a page because a simple condition is not met is not. For example, if you use a dictionary to look for text strings in Sitecore, you should assert that the dictionaty item is present in Sitecore before returning a value. But you should handle the exception nicely in your domain code so the entire page does not crash just because a dictionary text is missing.

About briancaos

Developer at Pentia A/S since 2003. Have developed Web Applications using Sitecore Since Sitecore 4.1.
This entry was posted in c#, General .NET, Sitecore 6 and tagged , , , , , . Bookmark the permalink.

2 Responses to Sitecore.Diagnostics.Assert statements

  1. commodore73 says:

    I think the only thing I don’t like about using Sitecore asserts is that they don’t prevent Visual Studio (or Reflector, or StyleCopy, or Agent Smith, or Agent Johnson, or something else I use with Visual Studio) from warning me that I haven’t checked for null if I use the asserted variable later in my code.

  2. commodore73 says:

    I also like how NUnit asserts can show expected and actual values – maybe not something you want to render on your public site, but then you probably shouldn’t be rendering anything about exceptions on your public site (see customErrors in web.config; I suggest RemoteOnly). For instance:

    NUnit.Framework.Assert.AreEqual(3, elements.Count, “primary nav li count” /* this third argument is optional*/);

    If elements.Count is 2, I see this in the browser:

    primary nav li count
    Expected: 3
    But was: 2

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s