Working friendly with null object references through extended functions
Introduction
I hate the null object reference error. It will decrease not only the quality but also the customer satisfaction. Entering the C# 3.0 times, the extended functions give us a powerful way to change our coding styles, including the approaches to null object references.
Rationalities for null references
However, the null object reference is reasonable. It is impossible to be eliminated from the codes. Dozens of codes will bring up null object references. They fall into at least three categories.
1.Widely used third-party components
Third party components prosper in the software development circles. It’s well-known that they boost the productivity, even the quality and scalability. However, not all the third party components are shipped with sufficient document to direct the programmers to code correctly with their interfaces, which will result in null object reference errors.
2.Web Services
In common sense, the response object returned from the web service proxy could not be null. However, the array in the response object will be null even if the web service returns an empty array instead of null.
3.List<T>.Find
Common approaches for null object references
Let’s start with a function definition.
public class TimeScheme {
public long SchemeID { get; set; }
public long[] TimeID { get; set; }
public string SchemeName { get; set; }
}
public void SaveObj(TimeScheme scheme, int count)
{
//...
}
The parameter list of SaveObj function contains two parameters. Parameter scheme is a reference type that may be null object reference. Parameter count is a value type that never causes null object reference error.
Approach 1: Just think they always have instances
Just ignore you are coding with reference types. Rather, handling them as the way as value types. Here is the pre-condition that they can’t be null. The code is as follows:
public void SaveObj(TimeScheme scheme, string name, int count)
{
switch (scheme.SchemeID)
{
case 1:
//do something
break;
case 2:
//do something
break;
}
}
If the scheme is null, the null object reference error arises. However, it is not bad. The pre-condition is that the scheme can not be null normally, if the null reference error arises, it indicates that something wrong in the running context. The exception will stop the error into the following workflow so that more serious bugs can be avoided. Meanwhile, the user and the programmer are alerted as well.
From the practical perspective, the code above is not effective to help us find the problem accurately. If the null object reference error appears in SaveObj, we can only get the message as the following form.
Test method MyTest.UnitTest1.TestNullReference threw exception: System.NullReferenceException: Object reference not set to an instance of an object.
MyTest.UnitTest1.SaveObj(TimeScheme scheme, String name, Int32 count) in C:\MyTest\UnitTest1.cs: line 131
In other words, we are alerted that null object reference arises in SaveObj function. However, we can’t figure out which reference value cause the error.
To be frank, the code above is almost useless to help us find out the problem. If we write more code to guard the scheme value, the error message will be more helpful.
public void SaveObj(TimeScheme scheme, string name, int count)
{
if (scheme == null)
throw new ArgumentNullException("scheme");
switch (scheme.SchemeID)
{
case 1:
//do something
break;
case 2:
//do something
break;
}
}
The error message will be the following.
Test method MyTest.UnitTest1.TestNullReference threw exception: System.ArgumentNullException: Value cannot be null.
Parameter name: scheme. MyTest.UnitTest1.SaveObj(TimeScheme scheme, String name, Int32 count) in C:\MyTest\UnitTest1.cs: line 131
However, if we implement this approach strictly, many codes as if(scheme==null) will be added. It will increase the code scale as well as the typing workloads. Here is the problem we will address.
Approach 2: Think they may be null references
Here is the pre-condition that they can be null. So we must keep it in mind, evaluating the variable before using them. The code will be written similar to the following form.
public void SaveObj(TimeScheme scheme, string name, int count)
{
if (scheme != null)
{
switch (scheme.SchemeID)
{
case 1:
//do something
break;
case 2:
//do something
break;
}
}
}
If we implement this approach strictly, many if-else codes will be introduced into the already-being-complex project. Can we make it simplier?
More practically, both of the pre-conditions may exist in the same context.
The Answer to the Null Object References
Since the null object references are reasonable, the answer would be how we can work friendly with the null object references substantially.
For pre-condition that the values can’t be null object references, the code will be written in this form.
public void SaveObj(TimeScheme scheme, string name, int count)
{
switch (scheme.UnSafeItem("scheme").SchemeID)
{
case 1:
//do something
break;
case 2:
//do something
break;
}
}
If the variable scheme is null, we can get the more helpful message as the following.Test method MyTest.UnitTest1.TestNullReference threw exception:
System.ArgumentNullException: Value cannot be null.
Parameter name: scheme.
Nova.SafeItems.ExtendedEnumerable.UnSafeItem[T](T item, String itemName) in C:\MyTest\SafeItems.cs: line 203
MyTest.UnitTest1.SaveObj(TimeScheme scheme, String name, Int32 count) in C:\MyTest\UnitTest1.cs: line 138
MyTest.UnitTest1.TestNullReference() in C:\MyTest\UnitTest1.cs: line 153
Oh, line 138 is line where the error occurs. We almost don’t change the code except the UnSafeItem(“scheme”), which is a extended method.
For pre-condition that the variable may be null object references, the code will be written in this form.
public void SaveObj(TimeScheme scheme, string name, int count)
{
scheme.SafeItem((n) => {
switch (n.SchemeID)
{
case 1:
//do something
break;
case 2:
//do something
break;
}
});
}
The switch block will be implemented only if scheme is not null.
SafeItem<T>(this T, Action<T>) makes sure that Action<T> is invoked only if variable T refers to a valid reference. UnSafeItem<T>(this T, string) throws ArgumentNullException if the variable T refers to null reference. In addition, more Safe series of extended functions are shipped in SafeItems.cs. I believe they will change the way of writing code.
Here I’d like to end up the writing with a comparison between the traditional codes and the extended safe codes in the real world.
[The traditional codes]
private static bool CheckTimes(SearchTimeParameter parameter, DateTime startDate)
{
if (parameter.IsXBooking
&& parameter.Item.CentralTimes != null && parameter.Item.Times.Length > 0)
{
foreach (DateTime time in parameter.Item.Times)
{
if (time.TimeOfDay == startDate.TimeOfDay)
{
return true;
}
}
return false;
}
else
{
return true;
}
}
[The extended safe codes]
private static bool CheckTimes(SearchTimeParameter parameter, DateTime startDate)
{
return !parameter.UnSafeItem("parameter").IsXBooking
|| parameter.Item.UnSafeItem("parameter.Item").Times.SafeCount == 0
|| parameter.Item.Times.SafeExists(time => time.TimeOfDay == startDate.TimeOfDay);
}
Don’t you think the extended safe codes are simpler?
Tips in UnSafeItem
UnSafeItem is just an idea in using the extended functions in C# 3.0.
public static T UnSafeItem<T>(this T item, string itemName) where T : class
{
if (item == null)
throw new ArgumentNullException(itemName);
else
return item;
}
I will appreciate any of your ideas.
