I completely disagree with this. NULL is meant to be an exceptional value, that's the reason it exists. That is it's default behavior.

I would argue that if you are finding it a problem, then the databases you're dealing with, or the code that acquires the data should be modified to handle the problem. NULL isn't a data value, it's an exception to data, so why should it be stored in a database? DBs can refuse null values, so if your column is marked not null, you have a reasonable assumption that you don't have to check it.

I don't think the problem is so much that null causes defensive code, I think the problem is that people have become desensitized to null values. They are exceptional, they do indicate problems (such as uninitialized values) and shouldn't be used for every day occurances.

The default case for your conditional, you answer your own question. If someCase is NOT A BOOLEAN, how can it be evaluated in a boolean expression? That would then raise the question, why can't I use "if (Blah)". Which would beg the question, how does Blah translate to true/false? Equally, how does null translate to true/false?


Consider if you had something like this (C++):
class Cat {
operator bool () const { return false; }
}
...
if (!someCat) {...

Is there a cat? or is there not a cat?

So.. can you imagine how insane debugging code like that could be when a null value slips through and null defaulted to false or true?

I want null exceptions, they make tracking down bugs easier. :)

Posted by Glitch on Apr 09, 2008 at 04:45 PM UTC - 5 hrs

Oh, and for my example above in C++..

C++ considers NULL to be 0. In C++/CLI nullptr gets the same treatment. So, converting the example above (since boolean operator would need dereferencing in C++ due to using pointers not references) to C++/CLI gives the functionality you're kind of suggesting.

Cat ^someCat = nullptr;
if (!someCat) // evaluates to true
someCat = gcnew Cat();
if (!someCat) // evaluates to true.

So, in reality.. null still needs to be accounted for.

Posted by Glitch on Apr 09, 2008 at 04:59 PM UTC - 5 hrs

You can use null most places in SQL where you'd use non-null values, but it almost always does something subtly weird. It's not equal to false, or zero, or an empty string, and it's not even equal to null. This makes sense to me, but I'm not sure that in a 3GL I'd prefer it to just dealing with exceptions. I definitely don't want nulls to start pretending they aren't nulls unless I explicitly ask them to.

On another level, if you have an object the null object pattern is a great way to deal with this - you can independently define null semantics for each class hierarchy. It's just a sad fact that nearly all our OO languages go all procedural on us at some point, beyond which we're back to writing != null.

Posted by Jaime Metcher on Apr 09, 2008 at 09:44 PM UTC - 5 hrs

> I want null exceptions, they make tracking down bugs easier.

I considered that - which is why I mentioned the bit about having a setting somewhere.

Re: null evaluating as false in boolean expressions, it can certainly happen - Both Javascript and Ruby (that I know of off the top of my head) consider null to be false.

In C and C++, as you mention null is 0 - and 0 evaluates to false IIRC.

I guess what I really want is for Java and C# (and ColdFusion, specifically for booleans) to have a different concept of NULL than they do. In CF, there is no null really - if you try to access a hash with a key that doesn't exist, it does throw an error. But if you get null from the DB it's just a blank string. This is irritating when you want to decide what to do based on a column that could be null.

But it's retarded in .NET, for example, if an Active Directory object does not have a value for a field, it's null. So, for every field before I do anything with it, I actually have to check to see if exists in that particular AD object.

I just think nulls are so common, that maybe they need a new construct or they should have thought about using null a bit harder depending on what is going on.

Jaime - I see what you're getting at- I wouldn't like that either. So, maybe I really want something else - but I'm having trouble finding words for it. I hope I can eventually do better than what I tried above. =)

The truth is there are cases where I care *a lot* about if an object is null, and there are cases where I don't care. Because of how prolific nulls are in everything, there spots I don't care far outnumber those where I do.

Posted by Sammy Larbi on Apr 10, 2008 at 04:19 PM UTC - 5 hrs

It kind of seems most of your dislikes are steming from the APIs and technologies external to the actual languages.

For instance, Active Directory. The reason most properties return null is because many of the default schema properties are MayContain properties. Which mean the object doesn't have to have those properties. So, if the object doesn't have the property, it only makes sense to return null (like any other property that isn't on the object). MustContain properties will always return the value they've been initialized with (and the object can't be created without initializing MustContain properties).

Likewise, a good database API (i hesitate to say like ADO.NET), provides wrapper objects like DataRow which contain methods to test for null columns. Even perl's db library returns undef for null columns.

I personally don't think any of these are the fault of the language. Unless the language specifically does something wrong (like evaluating null to ""), I don't see any reason to change the language for the faults of the APIs.

One thing to look at though, if the .NET libraries are truley frustrating, is extension methods for C# 3.0. You can write an extension method for say, Object that allows you to IsNull any object (even null references, since it is a compiler trick and not a real instance method). You could even implement a new method for specific classes to provide you with the default values you wanted.

Posted by Glitch on Apr 10, 2008 at 05:17 PM UTC - 5 hrs