In JavaScript undefined
can be reassigned, so it is often advised to create a self executing function that assures undefined is actually undefined. As an alternati
Because of this:
var myVar1;
var myVar2 = null;
if (myVar1 === null) alert('myVar1 is null');
if (myVar1 === undefined) alert('myVar1 is undefined');
if (myVar2 === null) alert('myVar2 is null');
if (myVar2 === undefined) alert('myVar2 is undefined');
Anything set to null is not undefined - it's defined as null.
The abstract equality algorithm from section 11.9.3 of the language spec is what defined ==
and !=
and it defines them such that
null == void 0
null == null
void 0 == null
where void 0
is just a reliable way of saying undefined
(see below) so the answer to your question is yes, null
is equal to undefined and itself and nothing else.
The relevant parts of the spec are
1. If Type(x) is the same as Type(y), then If Type(x) is Undefined, return true. If Type(x) is Null, return true. ... 2. If x is null and y is undefined, return true. 3. If x is undefined and y is null, return true. ...
If you're worried about undefined
meaning something other than what it normally means, use void 0
instead.
null == void 0 // True
({}).x === void 0 // True
"undefined" === typeof void 0 // True
(function () {})() === void 0 // True
(undefined = 42,
undefined === void 0) // False
"undefined" === typeof undefined // False
"undefined" === typeof void 0 // True
From the language specification:
11.4.2 The void Operator
The production UnaryExpression : void UnaryExpression is evaluated as follows:
- Let
expr
be the result of evaluating UnaryExpression/.- Call
GetValue(expr)
.- Return undefined.
So the void
prefix operator evaluates its argument and returns the special value undefined regardless of to what the global variable undefined
has been changed (or whether undefined
is defined :).
EDIT: In response to comments,
If you are dealing with library code that distinguishes between the two, then you need to deal with the difference. Some of the new libraries standardized by the language committee do ignore the difference : JSON.stringify([void 0]) === "[null]"
but there is too much code out there that treats them subtly differently, and there are other differences :
+(null) === 0
isNaN(+undefined)
"" + null === "null"
"" + undefined === "undefined"
If you're writing any kinds of libraries that produce text or serialize/deserialize and you want to conflate the two then you can't pass undefined
through and expect it to behave as null
-- you need to explicitly normalize your inputs to one or the other.
Reading Javascript: The Good parts, it seems that only null and undefined are equivalent
JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable. These are some of the interesting cases:
'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
' \t\r\n ' == 0 // true
"JavaScript: The Good Parts by Douglas Crockford. Copyright 2008 Yahoo! Inc., 978-0-596-51774-8."
Because JavaScript has both values. And while other languages may only have nil
/null
JavaScript grew up with undefined
being the "unknown value" while null
is clearly a known value to represent nothing.
Compare var x
where x
is undefined because no value has been assigned and var y = null
where y
is null
. It was set to something -- a sentential representing "nothing". This core fundamental usage of undefined
vs null
in JavaScript runs very deep and other cases include:
delete
'd) property also yield undefined
and not null
(it would result in null
only if null
had been assigned).undefined
.undefined
returned from standard functions like getElementById
Thus, in Javascript, it is often more correct to use undefined
and not null
. They both represent different things. A library that tries to fight this is fighting JavaScript.
Happy coding.
Personally, in almost all cases I avoid an explicit check for undefined
or null
. I believe that in most -- but not all -- cases all false values should be equivalent and that it is the callers responsibility to conform to the public contract stated.
Because of this belief I would consider the comparison x == null
on the verge of trying to guard too much and yet too little, but in the case of catching null
or undefined
, it works, as pointed out. Go start a trend ;-)