On Nov 4, 2010, at 10:32 AM, Peter van der Zee wrote:
> Shouldn't any var declared in the catch block be locally scoped as well?
var always hoists to top of function or program. Why would it be different in a
catch block? It's not in ES3, which standardized try/catch/finally.
> It seems that all browsers ignore that.
>
> try {x} catch(){ var y; } alert(y);
(Missing catch variable there.)
> The above should throw an error, yet it's undefined.
"should" by what standard?
var hoists, always. That's what the spec has said since ES1. The 'let' for
Harmony will be block scoped (as the catch variable is per ES3 and ES5), and
not hoisted (yay).
/be
> In fact, even if the catch
> is not thrown y still exists (but if the catch block is not processed as a
> seperate scope, I suppose that's to be expected).
>
> - peter
>
>> On Oct 11, 2010, at 4:40 PM, David Herman wrote:
>>
>>> ES3 `catch' is block-scoped. At the last face-to-face, we talked
>>> about statically disallowing var-declarations from hoisting past
>>> let-declarations:
>>>
>>> function f() {
>>> {
>>> let x = "inner";
>>> {
>>> var x = "outer"; // error: redeclaration } } }
>>>
>>> I just noticed a case I missed in the discussion, which has
>>> actually existed since ES3:
>>>
>>> function g() {
>>> try {
>>> throw "inner";
>>> } catch (x) {
>>> var x = "outer";
>>> }
>>> }
>>>
>>> This is allowed, and it binds a function-scoped variable x, while
>>> assigning "outer" to the catch-scoped variable x. This is pretty
>>> goofy, and almost certainly not what the programmer expects. And
>>> it's exactly analogous to the function f above, which
>>> SpiderMonkey currently rejects and we all agreed Harmony ought to
>>> reject.
>>>
>>> It's too late to add this case to ES5's strict mode restrictions,
>>> but I propose we ought to reject it in Harmony.
>>>
>> Dave caught this glitch in ES5 too late to fix before Ecma
>> submitted the spec to ISO. We can't change the ES5 spec now. We
>> will fix the spec later, but the change won't show up in a
>> normative spec for a while. Meanwhile, what implementations do has
>> more teeth than what a spec says.
>>
>> Mark Miller makes a good case that implementors should future-proof
>> against Harmony making this case an error by rejecting it from
>> their ES5 strict implementations. For Mozilla we plan to do this.
>> It would be good to get agreement from the rest of the big five, so
>> I'm taking the liberty of mailing you individually, cc'ing es-
>> discuss (where Mark and your avid fans await ;-).
>>
>> /be
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
