CHAPTER 27

Nullable Types
Null values are a useful programming construct beyond simply recording the initial state
of a class variable. In the database world, null conveys a notion of “no value recorded.” In
a survey, the answer to a question may be yes or no, but if a response isn’t provided, isn’t
available, or isn’t relevant to a particular respondent, you can record their response as null
rather than a definite yes or no. Because many applications deal with data that’s stored in
databases, where null values can be quite common, the ability to express null values
becomes quite important.
The inability to store nulls in value types can be a significant problem in C#. Value
types, by definition, consist of bits that either are allocated on the stack when they’re
declared as a local variable or are allocated inline when they form part of heap-allocated
types. Because a value type is always physically allocated, it has no ability to express an
unallocated or null value type. Further, since value types don’t have the luxury of an
object header (like reference types do), they don’t have a spare header bit that can
indicate an instance is null.
Dealing with the inability to express nullability becomes particularly troublesome
when dealing with data that originates from databases. Databases typically don’t have
separate concepts for reference and value types, and all data types can be null if the
schema allows. Before nullable types, recording null values in value types was a difficult
task. The following options existed:

* You could choose a special value to indicate logical null. For signed integers, -1
was often a reasonable choice; for floating points, NaN was popular. Finally, for
dates, DateTime.MinValue was often used.
* You could use a reference type that stored the value type internally and leave it as
null when appropriate. The types in System.Data.SqlTypes and various third-party
libraries were used in this role.
* You could maintain a boolean variable for every value type variable that could
potentially be null. The boolean would keep track of whether the accompanying
value type was logically null.

All of these alternatives had problems. Special values were often hard to define and
had the unfortunate tendency to end up back in the database if a developer wasn’t careful
with the update logic. This in turn created the painful problem of catering to both physical
and logical nulls. Using reference types was effective, but this data-tier local
implementation decision had a tendency of spreading through all tiers of an application,
which meant that the performance benefits offered by value types weren’t available. The
third alternative was generally the cleanest and simplest option, but it was cumbersome to
implement, particularly with method return values, and it also wasted space.
Because developers needed a general-purpose solution to value type nullability, and
because the designers of C# 2.0 were empowered by the addition of generics, they
extended the framework library to include the Nullable<T> value type. Nullable<T> can
take any value type as a type parameter, and it internally stores a boolean to track logical
nullness. This approach is essentially the same as the third option from the previous list
but is simpler from a logistical point of view, as only a single variable needs to be
tracked.
 Nullable<T> has various retrieval and informational methods:

Nullable<int> i = null;
bool b = i.HasValue; //will be false
int j = Nullable.GetValueOrDefault<int>(i); //returns 0
//j = i.Value; //will throw an exception
//j = (int)i; //will throw an exception
i = 123;
j = Nullable.GetValueOrDefault<int>(i); //returns 123
j = (int)123; //works fine

As you can see in the example, Nullable<T> allows both null and values that are legal
for the type parameter to be assigned to a Nullable<T> instance. You can use the
GetValueOrDefault method to retrieve the value, with the default value for the value type
returned if the instance is null. You can also use a cast to convert to a non-nullable
instance, but an exception will occur if the cast instance is logically null.

C# Language Nullable Types

The designers of the C# language figured the ability to convey nullability in value types
was important enough to elevate nullable types from a generic type in the framework
library into a fully fledged language feature. C# language nullable types map directly to
the Nullable<T> framework library type, so any other language that supports generics can
use C# nullable types. You express nullable types by adding a question mark after the
name of a value type, which indicates that the instance declared by the declaration can be
nullable:
int? i = null; //same as Nullable<int> i = null;
int? j = 0; // same as Nullable<int> j = 0;

To be a genuinely useful feature, nullable types need to act and feel like the value
type they represent. Thankfully, operations and conversion that work on the value type
will also work on the reference type. This means the following code will work with no
compile-time or runtime errors:
int? i = 1;
int? j = 2;
int? k = i + j; //addition operator works fine
double? d = k; //no problem with implicit conversion to double
short? s = (short?)d; //explicit cast required to short?
//because of possible data loss

For the case where none of the values in the equation is null, life is simple: the
operations and conversions behave in the same way as they would have if the values
hadn’t been nullable types. When null values are present, the situation becomes a little
more interesting. The basic rule is that the presence of a null value anywhere in the chain
results in a null result. Take the following example:
int? i = 1;
int? h = 2;
int? j = null;
int? k = i + j + h + 3;
double? d = k;
short? s = (short?)d;

In this case, the fact that j is null and is used in the addition results in k, d, and s
ending up null.
 User-defined operators work in much the same way as the built-in operators. If no
null values are present, the user-defined operations work in the same way as they would
with the non-nullable form of the types. If one or more null values are present anywhere
in the chain of operations, the result of the user-defined operation will be null.

SQL Language Differences and Similarities

In the C language, two null pointers are equal, as pointer comparison is simply a
comparison of two integral values. C# follows this pattern, and for equality operations,
two null values are defined as being equal, a behavior that’s in contrast to SQL logic
where null isn’t equal to null but instead is null.
During the C# 2.0 design process, the designers discussed this decision at length and
considered many options. One option was to support both the programming and database
versions of equality (null == null and null != null), but this would have required an
additional set of operators. The C# design team ultimately decided that approach would
add too much complexity. They decided using the database version of equality in code
would be surprising to the majority of C# programmers.
The following code highlights the different behavior between the two languages:
//C#
int? i = null;
int? j = null;
bool b = i == j;
//b with be true

--T_SQL
declare @i int
declare @j int
select @i = null
select @j = null

declare @b bit
if @i = @j
select @b = 1
else
select @b = 0
--@b will be zero.

In contrast to the difference in behavior between C# and SQL nullable types,

significant efforts have been made to ensure compatibility in several areas. The nullable
bool type has predefined operators for bitwise AND (&) and OR (|) operations that ensure
it has the same behavior as the equivalent SQL operations. This means a bitwise
operation on a bool? instance doesn’t necessary result in a null result, even if one of the
inputs into the operation is null. Clearly, a major exception to the main rule exists—a null
anywhere in a calculation chain results in the outcome of the calculation being null. The
following are a few examples:
bool? i = true;
bool? j = false;
bool? k = null;

bool? res1 = i | k; //returns true, NOT null

bool? res2 = j & k; //returns false, NOT null
Null Coalescing Operator
Just as the C# language provides a more streamlined syntax for expressing nullable types,
a more streamlined syntax exists for providing a default alternative if a nullable type
doesn’t hold a value. Rather than using the HasValue method and the ?: ternary
conditional operator to provide a default alternative, you can use the null coalescing
operator (??)—simply place the default value after the ?? operator:
int? x = null;
int y = x ?? 2; //x is null, y will be 2
//same as:
y = x.HasValue ? x. GetValueOrDefault() : 2;

x = 3;
y = x ?? 2; //x has a value and it will be returned, y will be 3

You have no need to cast the nullable type instance when using the coalescing
operator; the compiler will generate a call to GetValueOrDefault, which returns an instance
of the non-nullable value type.

Design Guidelines
When user interfaces and data tiers are written to present and manage data that’s persisted
to a database, nullable types make the exercise of dealing with value types that can be
null much easier. To achieve the smoothest development process with database code, one
of the essential elements is a consistent and reliable approach for mapping database types
to C# types and dealing with the changes, additions, and deletions in these types that
inevitably occur during the development cycle.
Because nullability is one of a number of attributes of any particular database field,
and because dealing with changes in nullability is no different from dealing with name
and data type changes, the idea of making a value type nullable in C# when it isn’t
nullable in the database just in case the underlying database schema changes makes little
sense. If the nullability of a field changes, simply use the same established change process
you’d use if an int field changed to a long field. Using nullable types unnecessarily is
detrimental to performance—memory is wasted storing a boolean value for each nullable
type and processor cycles are wasted checking this boolean when calculations involving
the nullable type are performed.
Don’t mix nullability concepts within an assembly. If you’re currently using special
values, System.Data.SqlTypes types, or third-party nullability libraries to deal with
nullability, don’t introduce Nullable<T> or C# nullable types without migrating existing
code to use these new features.