In JavaScript, there are two values which basically say 'I don't exist' - undefined
and null
.
A property to which a programmer has not assigned anything will be undefined
, but in order for a property to become null
, null
must be explicitly assigned to it.
I once thought that there was a need for null
because undefined
is a primitive value and null
an object. It's not, even if typeof null
will yield 'object'
: Actually, both are primitive values - which means neither undefined
nor null
can be returned from a constructor function, as both will be converted to an empty object (one has to throw an error to proclaim failure in constructors).
They also both evaluate to false
in boolean contexts. The only real difference I can think of is that one evaluates to NaN
, the other to 0
in numeric contexts.
So why is there both undefined
and null
if this just confuses programmers who are incorrectly checking for null
when trying to find out whether a property has been set or not?
What I'd like to know is if anyone has a reasonable example where it's necessary to use null
which couldn't be expressed using undefined
instead.
So the general consensus seems to be that undefined
means 'there is no such property' while null
means 'the property does exist, but holds no value'.
I could live with that if JavaScript implementations would actually enforce this behavior - but undefined
is a perfectly valid primitive value, so it can easily be assigned to existing properties to break this contract. Therefore, if you want to make sure if a property exists, you have to use the in
operator or hasOwnProperty()
anyway. So once again: what's the practical use for separate values for undefined
and null
?
I actually use undefined
when I want to unset the values of properties no longer in use but which I don't want to delete
. Should I use null
instead?
The question isn't really "why is there a null value in JS" - there is a null value of some sort in most languages and it is generally considered very useful.
The question is, "why is there an undefined value in JS". Major places where it is used:
var x;
but don't assign to it, x
holds undefined;null
would certainly have worked just as well for (1) and (2)*. (3) should really throw an exception straight away, and the fact that it doesn't, instead of returning this weird undefined
that will fail later, is a big source of debugging difficulty.
*: you could also argue that (2) should throw an exception, but then you'd have to provide a better, more explicit mechanism for default/variable arguments.
However JavaScript didn't originally have exceptions, or any way to ask an object if it had a member under a certain name - the only way was (and sometimes still is) to access the member and see what you get. Given that null
already had a purpose and you might well want to set a member to it, a different out-of-band value was required. So we have undefined
, it's problematic as you point out, and it's another great JavaScript 'feature' we'll never be able to get rid of.
I actually use undefined when I want to unset the values of properties no longer in use but which I don't want to delete. Should I use null instead?
Yes. Keep undefined
as a special value for signaling when other languages might throw an exception instead.
null
is generally better, except on some IE DOM interfaces where setting something to null
can give you an error. Often in this case setting to the empty string tends to work.