Stupid Question 91: Do we need NULL in C#?

I think we need the null-undefined combo in JavaScript even less 

So @Iris, I think there are two key issues.

**#1: Is null required?**
Yes, null support is required.in C#. The simplest example of this a DateTime field in, say, a Database. If I have a StartDate of Null, that means something different than any other reasonable value I can put there.

If I have a Nullable (or int?), the value of null generally means "not set", where the default integer value (0) can have some real meaning in my system.

**#2: returning null values from a function**
This case is less clear because it's not always clear what it means when the value of null is returned.

Let's say I have a Twitter API wrapper. If I request a specific Tweet via the wrapper and I get back a null, what does that mean? Does it mean that the Tweet doesn't exist? Does it mean I don't have auth? Could it be a timeout? If you're using the Twitter API, "does not exist" is very different from "could not connect to twitter".

In a case like this, I don't really want just a null. I want a null and some type of status code. In fact I want any non-successful call to include some type of "reason code" or "reason enum" and possibly a friendly message/exception, telling me what happened.

This last concept is not universal, there are perfectly acceptable reasons for returning null from a function. But if the function is public-facing, you really have to consider if the caller understands the meaning of null. 

null does represent nothingness, but nothing is a valid option.

The question is much like saying "Do we need Zero in our number system?"  Many number systems didn't have a concept of zero (Roman numbers, for example), but they've learned that those just aren't useful as numbers. 

Not quite true. Null is more like saying I haven't picked a number.

There are many examples where null is helpful, such as

IRefType value = null;
if(boolVal)
{
     value=new RefTypeA("whatever");
}
else
{
      value = new RefTypeB(2);
}

Arguably you could create implement the null object design pattern and set the initial interface to be the nullable object, but I think thats overkill personally.

Null coercion can be used in the example above which you might like the idea of i.e.:

String output = (value ?? new RefTypeNull()).Process();

I suppose it's a matter of maintainability, but from a defensive point of view the above does indicate intent quite nicely. 

I strive to use the Null Object design pattern -- please take a look at http://en.wikipedia.org/wiki/Null_Object_pattern -- as much as possible to help out client code of APIs I build not to encounter null exceptions.  

We should always assume  client code using our code is not robust  -- one example of non-robust code is code that does little to no null checks.

Mike 

My opinion is that NULL should not be returned from a method. Use an exception to signal failure instead.
Its use should be to represent that something hasn't been explicitly specified.
For example that a field hasn't been set. The alternative involves selecting a value in the valid range (for the datatype) to symbolize 'not set', normally an edge value. This introduces a so called magic value, a normal value that has special meaning in this context. It will be confusing for everyone, probably even for the programmer that wrote the code if he comes back a year later. NULL is  outside the value range and makes the intent more clear.
Also, if it is a form that the user fills in, how can you know whether the user actually wants the magic value or if he/she just haven't touched the field? 

"Null is more like saying I haven’t picked a number."  
This is only true when you are talking about numbers.  But consider a actual object (reference type).  It either exists or it doesn't.  How do you express "doesn't exist" without NULL?