Why does ` == null` give a SyntaxError? [duplicate]
This question already has an answer here:
Why is + no longer NaN in Chrome console?
3 answers
Why does commuting the arguments of == in a console change the output?
2 answers
Why does == false throw an exception?
1 answer
Odd behaviour of comparison of object literals
4 answers
I can compare to true or false or itself, but comparison to null or undefined gives a syntax error. Is this because is an object value and not a reference? It feels weird that it would be a Syntax Error instead of some kind of runtime type error, or just work.
To clarify, I'm curious why this is a SyntaxError, mostly compared to doing == which is not only not a SyntaxError, but no error at all.
javascript
google-chrome asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
marked as duplicate by abc123, Bergi javascript
Users with the javascript badge can single-handedly close javascript questions as duplicates and reopen them as needed.
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 14 '18 at 19:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
|
show 17 more comments
This question already has an answer here:
Why is + no longer NaN in Chrome console?
3 answers
Why does commuting the arguments of == in a console change the output?
2 answers
Why does == false throw an exception?
1 answer
Odd behaviour of comparison of object literals
4 answers
I can compare to true or false or itself, but comparison to null or undefined gives a syntax error. Is this because is an object value and not a reference? It feels weird that it would be a Syntax Error instead of some kind of runtime type error, or just work.
To clarify, I'm curious why this is a SyntaxError, mostly compared to doing == which is not only not a SyntaxError, but no error at all.
javascript
google-chrome asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
marked as duplicate by abc123, Bergi javascript
Users with the javascript badge can single-handedly close javascript questions as duplicates and reopen them as needed.
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 14 '18 at 19:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
6
for some reason the REPL seems to treat it as a block statement there
– Jonas Wilms
Nov 14 '18 at 18:34
When you put everything in parentheses,( == null), it returns false. Firefox doesn't like comparing it at all:==throws a syntax error, except if you put in parentheses.
– joppiesaus
Nov 14 '18 at 18:41
2
stackoverflow.com/questions/9032856/…
– epascarello
Nov 14 '18 at 18:47
#3 in the dupe. is seen as a block statement that does not return anything so it is same asundefined == null
– epascarello
Nov 14 '18 at 18:53
1
@felixKling bergi linked the relevant source in the dupe, its just a regex to check forand, which is ... pragmatic....
– Jonas Wilms
Nov 14 '18 at 19:27
|
show 17 more comments
This question already has an answer here:
Why is + no longer NaN in Chrome console?
3 answers
Why does commuting the arguments of == in a console change the output?
2 answers
Why does == false throw an exception?
1 answer
Odd behaviour of comparison of object literals
4 answers
I can compare to true or false or itself, but comparison to null or undefined gives a syntax error. Is this because is an object value and not a reference? It feels weird that it would be a Syntax Error instead of some kind of runtime type error, or just work.
To clarify, I'm curious why this is a SyntaxError, mostly compared to doing == which is not only not a SyntaxError, but no error at all.
javascript
google-chrome asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
This question already has an answer here:
Why is + no longer NaN in Chrome console?
3 answers
Why does commuting the arguments of == in a console change the output?
2 answers
Why does == false throw an exception?
1 answer
Odd behaviour of comparison of object literals
4 answers
I can compare to true or false or itself, but comparison to null or undefined gives a syntax error. Is this because is an object value and not a reference? It feels weird that it would be a Syntax Error instead of some kind of runtime type error, or just work.
To clarify, I'm curious why this is a SyntaxError, mostly compared to doing == which is not only not a SyntaxError, but no error at all.
This question already has an answer here:
Why is + no longer NaN in Chrome console?
3 answers
Why does commuting the arguments of == in a console change the output?
2 answers
Why does == false throw an exception?
1 answer
Odd behaviour of comparison of object literals
4 answers
javascript
google-chrome javascript
google-chrome asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
edited Nov 14 '18 at 19:13
Christopher Wirt
asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
asked Nov 14 '18 at 18:32
Christopher WirtChristopher Wirt
812719
812719
marked as duplicate by abc123, Bergi javascript
Users with the javascript badge can single-handedly close javascript questions as duplicates and reopen them as needed.
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 14 '18 at 19:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by abc123, Bergi javascript
Users with the javascript badge can single-handedly close javascript questions as duplicates and reopen them as needed.
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 14 '18 at 19:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
6
for some reason the REPL seems to treat it as a block statement there
– Jonas Wilms
Nov 14 '18 at 18:34
When you put everything in parentheses,( == null), it returns false. Firefox doesn't like comparing it at all:==throws a syntax error, except if you put in parentheses.
– joppiesaus
Nov 14 '18 at 18:41
2
stackoverflow.com/questions/9032856/…
– epascarello
Nov 14 '18 at 18:47
#3 in the dupe. is seen as a block statement that does not return anything so it is same asundefined == null
– epascarello
Nov 14 '18 at 18:53
1
@felixKling bergi linked the relevant source in the dupe, its just a regex to check forand, which is ... pragmatic....
– Jonas Wilms
Nov 14 '18 at 19:27
|
show 17 more comments
6
for some reason the REPL seems to treat it as a block statement there
– Jonas Wilms
Nov 14 '18 at 18:34
When you put everything in parentheses,( == null), it returns false. Firefox doesn't like comparing it at all:==throws a syntax error, except if you put in parentheses.
– joppiesaus
Nov 14 '18 at 18:41
2
stackoverflow.com/questions/9032856/…
– epascarello
Nov 14 '18 at 18:47
#3 in the dupe. is seen as a block statement that does not return anything so it is same asundefined == null
– epascarello
Nov 14 '18 at 18:53
1
@felixKling bergi linked the relevant source in the dupe, its just a regex to check forand, which is ... pragmatic....
– Jonas Wilms
Nov 14 '18 at 19:27
6
6
for some reason the REPL seems to treat it as a block statement there
– Jonas Wilms
Nov 14 '18 at 18:34
for some reason the REPL seems to treat it as a block statement there
– Jonas Wilms
Nov 14 '18 at 18:34
When you put everything in parentheses,
( == null), it returns false. Firefox doesn't like comparing it at all: == throws a syntax error, except if you put in parentheses.– joppiesaus
Nov 14 '18 at 18:41
When you put everything in parentheses,
( == null), it returns false. Firefox doesn't like comparing it at all: == throws a syntax error, except if you put in parentheses.– joppiesaus
Nov 14 '18 at 18:41
2
2
stackoverflow.com/questions/9032856/…
– epascarello
Nov 14 '18 at 18:47
stackoverflow.com/questions/9032856/…
– epascarello
Nov 14 '18 at 18:47
#3 in the dupe. is seen as a block statement that does not return anything so it is same as
undefined == null– epascarello
Nov 14 '18 at 18:53
#3 in the dupe. is seen as a block statement that does not return anything so it is same as
undefined == null– epascarello
Nov 14 '18 at 18:53
1
1
@felixKling bergi linked the relevant source in the dupe, its just a regex to check for
– Jonas Wilms
Nov 14 '18 at 19:27
@felixKling bergi linked the relevant source in the dupe, its just a regex to check for
– Jonas Wilms
Nov 14 '18 at 19:27
|
show 17 more comments
1 Answer
1
active
oldest
votes
There are two main contexts when parsing code: the expression context and the statement context. The body of a function for example is a statement context, the right side of an assignment is an expression context. To distinguish both makes sense to forbid things like:
if( if(true) ) alert("nonsense");
Now REPL have a really difficult task: On the one hand, they have to parse functions and codeblocks that get entered, and on the other hand you sometimes just want to check how a certain object look like. Therefore this:
a: 1, b: 2
is actually a SyntaxError in JavaScript, as a { in a statement context starts a block of code, and : is invalid then. However the REPL is clever enough and puts that object into an expression context, and evaluates it as if it would be in parens:
( a: 1, b: 2 )
the same happens for:
==
which is actually also a SyntaxError, however the REPL also moves it into an expression context:
( == )
That "moving into an expression context" is a complicated task, and it seems as if the REPL just does not see the expression here:
== null
and therefore parses as a block. Thats the case because the REPL just naively checks if the first and the last character are and , which is the case for == but not for == null.
Relevant part of the chromium sourcecode:
if (/^s*/.test(text) && /s*$/.test(text))
text = '(' + text + ')';
executionContext.evaluate(text, "console", !!useCommandLineAPI, false, false, true, printResult);
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
1
I'm really glad someone else was as interested in this dumb bit of REPL weirdness as I was :)
– Christopher Wirt
Nov 14 '18 at 19:31
1
@christopher I'm really surprised that there are so many duplicates ... I never heard of this behaviour before ....
– Jonas Wilms
Nov 14 '18 at 19:33
2
mad props for finding the relevant bit of chromium sourcecode
– Caleb Jay
Nov 14 '18 at 22:41
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are two main contexts when parsing code: the expression context and the statement context. The body of a function for example is a statement context, the right side of an assignment is an expression context. To distinguish both makes sense to forbid things like:
if( if(true) ) alert("nonsense");
Now REPL have a really difficult task: On the one hand, they have to parse functions and codeblocks that get entered, and on the other hand you sometimes just want to check how a certain object look like. Therefore this:
a: 1, b: 2
is actually a SyntaxError in JavaScript, as a { in a statement context starts a block of code, and : is invalid then. However the REPL is clever enough and puts that object into an expression context, and evaluates it as if it would be in parens:
( a: 1, b: 2 )
the same happens for:
==
which is actually also a SyntaxError, however the REPL also moves it into an expression context:
( == )
That "moving into an expression context" is a complicated task, and it seems as if the REPL just does not see the expression here:
== null
and therefore parses as a block. Thats the case because the REPL just naively checks if the first and the last character are and , which is the case for == but not for == null.
Relevant part of the chromium sourcecode:
if (/^s*/.test(text) && /s*$/.test(text))
text = '(' + text + ')';
executionContext.evaluate(text, "console", !!useCommandLineAPI, false, false, true, printResult);
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
1
I'm really glad someone else was as interested in this dumb bit of REPL weirdness as I was :)
– Christopher Wirt
Nov 14 '18 at 19:31
1
@christopher I'm really surprised that there are so many duplicates ... I never heard of this behaviour before ....
– Jonas Wilms
Nov 14 '18 at 19:33
2
mad props for finding the relevant bit of chromium sourcecode
– Caleb Jay
Nov 14 '18 at 22:41
add a comment |
There are two main contexts when parsing code: the expression context and the statement context. The body of a function for example is a statement context, the right side of an assignment is an expression context. To distinguish both makes sense to forbid things like:
if( if(true) ) alert("nonsense");
Now REPL have a really difficult task: On the one hand, they have to parse functions and codeblocks that get entered, and on the other hand you sometimes just want to check how a certain object look like. Therefore this:
a: 1, b: 2
is actually a SyntaxError in JavaScript, as a { in a statement context starts a block of code, and : is invalid then. However the REPL is clever enough and puts that object into an expression context, and evaluates it as if it would be in parens:
( a: 1, b: 2 )
the same happens for:
==
which is actually also a SyntaxError, however the REPL also moves it into an expression context:
( == )
That "moving into an expression context" is a complicated task, and it seems as if the REPL just does not see the expression here:
== null
and therefore parses as a block. Thats the case because the REPL just naively checks if the first and the last character are and , which is the case for == but not for == null.
Relevant part of the chromium sourcecode:
if (/^s*/.test(text) && /s*$/.test(text))
text = '(' + text + ')';
executionContext.evaluate(text, "console", !!useCommandLineAPI, false, false, true, printResult);
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
1
I'm really glad someone else was as interested in this dumb bit of REPL weirdness as I was :)
– Christopher Wirt
Nov 14 '18 at 19:31
1
@christopher I'm really surprised that there are so many duplicates ... I never heard of this behaviour before ....
– Jonas Wilms
Nov 14 '18 at 19:33
2
mad props for finding the relevant bit of chromium sourcecode
– Caleb Jay
Nov 14 '18 at 22:41
add a comment |
There are two main contexts when parsing code: the expression context and the statement context. The body of a function for example is a statement context, the right side of an assignment is an expression context. To distinguish both makes sense to forbid things like:
if( if(true) ) alert("nonsense");
Now REPL have a really difficult task: On the one hand, they have to parse functions and codeblocks that get entered, and on the other hand you sometimes just want to check how a certain object look like. Therefore this:
a: 1, b: 2
is actually a SyntaxError in JavaScript, as a { in a statement context starts a block of code, and : is invalid then. However the REPL is clever enough and puts that object into an expression context, and evaluates it as if it would be in parens:
( a: 1, b: 2 )
the same happens for:
==
which is actually also a SyntaxError, however the REPL also moves it into an expression context:
( == )
That "moving into an expression context" is a complicated task, and it seems as if the REPL just does not see the expression here:
== null
and therefore parses as a block. Thats the case because the REPL just naively checks if the first and the last character are and , which is the case for == but not for == null.
Relevant part of the chromium sourcecode:
if (/^s*/.test(text) && /s*$/.test(text))
text = '(' + text + ')';
executionContext.evaluate(text, "console", !!useCommandLineAPI, false, false, true, printResult);
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
There are two main contexts when parsing code: the expression context and the statement context. The body of a function for example is a statement context, the right side of an assignment is an expression context. To distinguish both makes sense to forbid things like:
if( if(true) ) alert("nonsense");
Now REPL have a really difficult task: On the one hand, they have to parse functions and codeblocks that get entered, and on the other hand you sometimes just want to check how a certain object look like. Therefore this:
a: 1, b: 2
is actually a SyntaxError in JavaScript, as a { in a statement context starts a block of code, and : is invalid then. However the REPL is clever enough and puts that object into an expression context, and evaluates it as if it would be in parens:
( a: 1, b: 2 )
the same happens for:
==
which is actually also a SyntaxError, however the REPL also moves it into an expression context:
( == )
That "moving into an expression context" is a complicated task, and it seems as if the REPL just does not see the expression here:
== null
and therefore parses as a block. Thats the case because the REPL just naively checks if the first and the last character are and , which is the case for == but not for == null.
Relevant part of the chromium sourcecode:
if (/^s*/.test(text) && /s*$/.test(text))
text = '(' + text + ')';
executionContext.evaluate(text, "console", !!useCommandLineAPI, false, false, true, printResult);
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
edited Nov 14 '18 at 19:23
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
answered Nov 14 '18 at 19:17
Jonas WilmsJonas Wilms
59.1k53152
59.1k53152
1
I'm really glad someone else was as interested in this dumb bit of REPL weirdness as I was :)
– Christopher Wirt
Nov 14 '18 at 19:31
1
@christopher I'm really surprised that there are so many duplicates ... I never heard of this behaviour before ....
– Jonas Wilms
Nov 14 '18 at 19:33
2
mad props for finding the relevant bit of chromium sourcecode
– Caleb Jay
Nov 14 '18 at 22:41
add a comment |
1
I'm really glad someone else was as interested in this dumb bit of REPL weirdness as I was :)
– Christopher Wirt
Nov 14 '18 at 19:31
1
@christopher I'm really surprised that there are so many duplicates ... I never heard of this behaviour before ....
– Jonas Wilms
Nov 14 '18 at 19:33
2
mad props for finding the relevant bit of chromium sourcecode
– Caleb Jay
Nov 14 '18 at 22:41
1
1
I'm really glad someone else was as interested in this dumb bit of REPL weirdness as I was :)
– Christopher Wirt
Nov 14 '18 at 19:31
I'm really glad someone else was as interested in this dumb bit of REPL weirdness as I was :)
– Christopher Wirt
Nov 14 '18 at 19:31
1
1
@christopher I'm really surprised that there are so many duplicates ... I never heard of this behaviour before ....
– Jonas Wilms
Nov 14 '18 at 19:33
@christopher I'm really surprised that there are so many duplicates ... I never heard of this behaviour before ....
– Jonas Wilms
Nov 14 '18 at 19:33
2
2
mad props for finding the relevant bit of chromium sourcecode
– Caleb Jay
Nov 14 '18 at 22:41
mad props for finding the relevant bit of chromium sourcecode
– Caleb Jay
Nov 14 '18 at 22:41
add a comment |
6
for some reason the REPL seems to treat it as a block statement there
– Jonas Wilms
Nov 14 '18 at 18:34
When you put everything in parentheses,
( == null), it returns false. Firefox doesn't like comparing it at all:==throws a syntax error, except if you put in parentheses.– joppiesaus
Nov 14 '18 at 18:41
2
stackoverflow.com/questions/9032856/…
– epascarello
Nov 14 '18 at 18:47
#3 in the dupe. is seen as a block statement that does not return anything so it is same as
undefined == null– epascarello
Nov 14 '18 at 18:53
1
@felixKling bergi linked the relevant source in the dupe, its just a regex to check for
and, which is ... pragmatic....– Jonas Wilms
Nov 14 '18 at 19:27