Throwing an error while declaring a constant causes unallocable identifier name
Reported by
hakerh403@gmail.com,
Jan 2 2017
|
||||||
Issue description
Chrome Version : 55.0.2883.87 (Official Build) m (64-bit)
URLs (if applicable) : /
Other browsers tested:
Safari: <?>
Firefox: OK
IE: <?>
If we throw an error in a self invoking function in constant declaration, the identifier name will be allocated, but we cannot access it (it will throw ReferenceError). Here is an example:
const a = (() => {throw 0;})();
It will throw 0. But, after that, we can no longer reference identifier `a`. Referencing it will throw ReferenceError. Also, executing `typeof a` will throw ReferenceError too. Maybe I am wrong, but as I know, it is contradictory with ES7 specification.
According to ES7, the above example should throw 0, as expected, but identifier `a` will be a constant which has undefined value. We should be able to reference it. Also, as I know, the only two cases when `typeof a` will throw an ReferenceError is 1) when `a` is property of global object whose `get` internal method will throw a ReferenceError and 2) when `a` is referenced inside `with` statement in non strict mode and object we are using in `with` has property `a` which has `get` internal method which actually throws ReferenceError. Normally, just calling `typeof a` should not throw any errors, but in the example above it does.
In Firefox, it works as expected. Declaration line throws 0, but constant is created, its value is undefined and we can reference it without any errors.
Here is an image of how it looks: https://i.imgur.com/ePMdcnJ.png
As you can see, even creating a constant with the same name will throw an error, but this time SyntaxError.
,
Jan 4 2017
,
Jan 4 2017
Looks like both Chrome and FireFox has similar output.Could you please update further on this whats is the expected output.
Chrome 55.0.2883.87 on Win 10 output:
=======================================
1) const a = (() => {throw 0;})();
Uncaught 0
2) const a = (() => {throw 0;})();
Uncaught SyntaxError: Identifier 'a' has already been declared
3) const a = (() => {throw 0;})();
Uncaught SyntaxError: Identifier 'a' has already been declared
4)typeof a;
Uncaught ReferenceError: a is not defined
Fire Fox out put:
=================
1) const a = (() => {throw 0;})();
0
2) const a = (() => {throw 0;})();
SyntaxError: redeclaration of const a
3) const a = (() => {throw 0;})();
SyntaxError: redeclaration of const a
4)typeof a
"undefined"
,
Jan 5 2017
Well, "similar output" is very different from "same output". Difference is because Chrome throws ReferenceError when you try to access that identifier, while Firefox allows you to do that, but of course, its value is undefined. Correct me if I am wrong, but according to specs (https://www.ecma-international.org/ecma-262/7.0/) the output should be like in Firefox. Executing `typeof a` should not throw an error. Also, referencing that identifier should not throw an error. The similar thing in both browsers is that you cannot, of course, redeclare the same constant identifier. That is ok. But Chrome simply allocated identifier name, but doesn't let you access it.
,
Jan 9 2017
,
Jan 9 2017
Chrome's is the correct behavior per spec. What you're seeing in Firefox is either a symptom of them not yet supporting ES2015 semantics, or a feature of their development console. The latter seems to be the case when I run this in their jsshell (a command-line version of Firefox's SpiderMonkey JS engine):
```
js> const a = (() => {throw 0;})();
uncaught exception: 0
(Unable to print stack trace)
Warning: According to the standard, after the above exception,
Warning: the global bindings should be permanently uninitialized.
Warning: We have non-standard-ly initialized them to `undefined`for you.
Warning: This nicety only happens in the JS shell.
```
,
Jan 18 2017
See https://esdiscuss.org/topic/global-lexical-tier for recent standards body discussion, where this issue was raised and we ended up sticking with the current behavior. Pavel, should we consider implementing Firefox's behavior in the DevTools console? This bug is not the first time such a complaint has come up. That es-discuss thread specifically endorses consoles implementing slightly different semantics like this. It seems to me like the error is more likely to come up interactively than in websites (where it is also observable, e.g., from multiple script tags). |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dtapu...@chromium.org
, Jan 3 2017