Version: (using KDE KDE 3.4.0) Installed from: Unlisted Binary Package OS: Linux Even when having a "var"-keyword before an identifier, the identifier within a catch-clause should refer to the passed exception (if it's the same identifier): try { ... } catch (x) { var x = "anything"; // the local x of the catch-clause } the attached example makes it (hopefully more clear). (and I agree: it's a dump rule).
Created attachment 11677 [details] example demonstrating the bad symbol resolution. executing the example should alert "2" and "undefined". current versions print "any exception" and "2".
btw: the relevant ECMA-script sections is section 12.2: "Evaluate Identifier as described in 11.1.2". and 11.1.2 explains the default scoping rules (so not different from an affection without the "var"-keyword).
My copy of the ECMAScript standard does not say "Evaluate Identifier as described in 11.1.2". It says that the variable should be added as a property to an object added to the scope chain. That's what we do. But Firefox behaves differently as you suggest. Internet Explorer again calls alert() with "2" and "2" revealing a hybrid behaviour. What shall we do?
nice that somebody is looking at this. The section should still be there. Just a little bit further down. I'll enlarge the 'relevant section' part: 12.2 - Description (page 62): 'Variables are created when the execution scope is entered' 'Only Program and FunctionDeclaration produce a new scope.' IMHO this means that a function (and program) has to look for all 'var' statements in its local scope and initialize them to undefined. When then encountering the 'var id = expr' statement we should apply the rules of page 63. starting with: '1. Evaluate Identifier as described in 11.1.2' If we are in an exception scope we have however: 12.4 (page 70) catch-part: '4. Add Result(2) to the front of the scope chain.' According to rule 11.1.2 which refers to 10.1.4 (the usual identifier resolution) we have to traverse the scope chain to find the id. And now it has been added due to the 'catch' block. To summarize: half of 'var id = expr' should be done when entering the function scope. Half of it later, but at the 'later' moment the id doesn't refer to the same var anymore. I would compare it to the 'with' statement which has similar effects.
I am pretty sure 2, undefined is the proper behavior: 1) var is handled at processVarDecls stage, and inserts an x = undefined into function's ActivationImp. 2) catch pushes a new object, with a new 'x' property onto chain (12.14) 3) var x = 2 -executes-, and assigns 2 into the current scope's x. 4) catch's scope is poped from both I think saw some potentially related commit in JSC, will add a link once I get that late in changelog (no soon, leaving right now.)
I managed to make the same mistake when doing bytecode transition (also for 'while'). Problem is, Firefox3 seems to fail your testcase now. FF2 didn't. I think I'll go ahead and fix this, but one day it may come back and bite us.
SVN commit 826069 by orlovich: Make sure to dynamically bind var-statements on execution within catch and with contexts. BUG:108538 M +12 -3 nodes2bytecode.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=826069