Don’t Break the Interface

Recently while contributing to a test suite that covers some 250 C# DAOs (Data Access Objects) I discovered a couple of issues:

1) There was an implementation of “PrimaryKey” which is defined as a nullable long (long? PrimaryKey) that returned a 0 (zero) if the nullable type had no value. Uh-Oh!

2) There was more than one implementation, e.g., this actually appeared in more than one base class, in different assemblies. Depending on which references you had set, you could get clobbered!

Needless to say we’re going to fix that quickly; there are objects that are “older code” that need to be updated to reflect the change.

Fortunately our test suite will show immediately which guys need to be updated,underscoring the importance of having robust unit tests.

But the real question is, “How did this creep in”? The answer: Most probably, "Stinkin' Thinkin'" by developers.

Nullable types are instances of the System.Nullable struct. A nullable type can represent the normal range of values for its underlying value type, plus an additional null value.

For example, a Nullable<Int32>, pronounced "Nullable of Int32," can be assigned any value from -2147483648 to 2147483647, or it can be assigned the null value. A Nullable bool can be assigned the values true or false, or null. The ability to assign null to numeric and Boolean types is particularly useful when dealing with databases and other data types containing elements that may not be assigned a value. For example, a Boolean field in a database can store the values true or false, or it may be undefined.

An example from the MSDN documentation:

Class NullableExample
{
static void Main()
{
int? num = null;
if (num.HasValue == true)
{
System.Console.WriteLine("num = " + num.Value);
}
else
{
System.Console.WriteLine("num = Null");
}

//y is set to zero
int y = num.GetValueOrDefault();

// num.Value throws an InvalidOperationException if num.HasValue is false
try
{
y = num.Value;
}
catch (System.InvalidOperationException e)
{
System.Console.WriteLine(e.Message);
}
}
}

The above will display the output:

num = Null

Nullable object must have a value.

Nullable types have the following characteristics:

• Nullable types represent value-type variables that can be assigned the value of null. You cannot create a nullable type based on a reference type. (Reference types already support the null value.)

• The syntax T? is shorthand for System.Nullable, where T is a value type. The two forms are interchangeable.

• Assign a value to a nullable type in the same way as for an ordinary value type, for example int? x = 10; or double? d = 4.108;

• Use the System.Nullable.GetValueOrDefault property to return either the assigned value, or the default value for the underlying type if the value is null, for example int j = x.GetValueOrDefault();

• Use the HasValue and Value read-only properties to test for null and retrieve the value, for example if(x.HasValue) j = x.Value;

  • The HasValue property returns true if the variable contains a value, or false if it is null.

  • The Value property returns a value if one is assigned, otherwise a System.InvalidOperationException is thrown.

  • The default value for a nullable type variable sets HasValue to false. The Value is undefined.

• Use the ?? operator to assign a default value that will be applied when a nullable type whose current value is null is assigned to a non-nullable type, for example int? x = null; int y = x ?? -1;

• Nested nullable types are not allowed. The following line will not compile: Nullable<nullable> n;

The bottom line? Good communication between members of the developer team ensures consistency and that the interface won’t be broken. This includes the mistake of having base types or interface members declared in multiple places -the functional equivalent of "breaking the interface". And, it’s important to understand the “Nullable Object must have a value” exception and why it happens, cryptic as the exception may seem.