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)
{
  DoStuff(null);
}

private void DoStuff(Item item)
{
  Sitecore.Diagnostics.Assert.ArgumentNotNull(item, "item"); // Assertion
  Response.Write(item.Paths.FullPath);
}

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");
  Response.Write(item.Paths.FullPath);
}

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");
  Response.Write(item.Paths.FullPath);
}

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.