Closed
Bug 593176
Opened 14 years ago
Closed 14 years ago
Cannot use functions declared later in try..catch block
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
DUPLICATE
of bug 585536
People
(Reporter: sereda, Unassigned)
References
Details
(Whiteboard: [tracing])
Attachments
(1 file)
|
(deleted),
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
Normally, a function statement placement within a block is not relevant - you can call it from any place within its scope. However, if you place the whole code in try..catch block, the function cannot be used.
See the test code.
It works normally in other browsers.
Reproducible: Always
Steps to Reproduce:
1. Open the test code
Actual Results:
ok
fail: ReferenceError: definedLater is not defined
ok
Expected Results:
ok
ok
ok
<html>
<body>
<div id="e1"></div>
<div id="e2"></div>
<div id="e3"></div>
<script type="text/javascript">
function e1() {
return definedLater();
function definedLater() { return "ok"; }
}
function e2() {
try {
return definedLater();
function definedLater() { return "ok"; }
} catch (e) {
return "fail: " + e;
}
}
function e3() {
try {
function definedEarlier() { return "ok"; }
return definedEarlier();
} catch (e) {
return "fail: " + e;
}
}
document.getElementById('e1').innerHTML = e1();
document.getElementById('e2').innerHTML = e2();
document.getElementById('e3').innerHTML = e3();
</script>
</body>
</html>
|
||
Updated•14 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
|
Reporter | |
Comment 2•14 years ago
|
||
I'm not sure I see how this is a duplicate of #585536, which says "Function statements should be block-local".
Even if the function statement in this case is NOT block-local (I presume it has some bigger scope), how can it be undefined?
In both cases (e1 and e2) the function statement is in the same block with the function call - it works in one case and doesn't work in the other.
Thanks
Igor
|
|
Reporter | |
Comment 3•14 years ago
|
||
In case you think the problem is with definedLater() being redefined, the following does not work either:
<html>
<body>
<div id="e2"></div>
<script type="text/javascript">
function e2() {
try {
return definedLater();
function definedLater() { return "ok"; }
} catch (e) {
return "fail: " + e;
}
}
document.getElementById('e2').innerHTML = e2();
</script>
</body>
</html>
Actual Results:
fail: ReferenceError: definedLater is not defined
Expected Results:
ok
|
|
||
Comment 4•14 years ago
|
||
Igor, please see ES5 (http://www.ecmascript.org/ has a link) or earlier. The standards do not specify function definitions as sub-statements, only at the top level of a program or a function body. You are seeing an extension which behaves differently in different browsers.
The function statement extension we have supported for ~13 years binds the name only if control flow reaches the definition.
IE hoists all function definitions, even in subordinate statements (last one in source order wins). Other browsers emulate this, more or less. But it will not be standardized.
The "Harmony" agreement for future JS standards includes a spec for functions in blocks (braced block statements; try, catch, and finally clauses). These bind their name in the block scope, with the binding hoisted so it is available when the block is entered. See:
http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings
Therefore I've dup'ed against bug 585536, since it is the only way forward by agreement of all the vendors and others participating in Ecma TC39. It is an incompatible change for all browser JS implementations. It will not provide "conditional bindings" as our extension does today, nor will it provide "hoisted to top of body or program, last one wins" as in IE. But it will do what you ask for in comment 0.
/be
|
|
||
Comment 5•14 years ago
|
||
This has come up before in other bugs, e.g., bug 434912. It is also a topic on es-discuss over the years, e.g. at
https://mail.mozilla.org/pipermail/es-discuss/2007-March/003964.html
https://mail.mozilla.org/pipermail/es-discuss/2008-February/005314.html
/be
Status: RESOLVED → VERIFIED
|
|
Reporter | |
Comment 6•14 years ago
|
||
Brendan, thanks a lot for the extensive explanation! My fault, I missed that part of the language spec. I guess I will need to move all function declarations to the beginning of the enclosing function.
Cheers,
Igor
|
|
||
Comment 7•14 years ago
|
||
Or just to top-level in the enclosing function body, and they'll hoist as if they were declared first (order preserved).
/be
|
||
Comment 9•12 years ago
|
||
Hello Guys,
I have reproduced this bug on my FF15:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
I have attached test case which I have used.
|
||
Updated•11 years ago
|
Whiteboard: [tracing]
You need to log in
before you can comment on or make changes to this bug.
Description
•