Why do catch clauses have their own lexical environment?

Solution 1:

Yes, catch clauses indeed have their own Lexical Environments. Check out what happens when it is evaluated: It creates a new one (deriving from the current one) and binds the exception-identifier to it. When executing the catch block, the current Execution Context's LexicalEnvironment is switched to the new one, while the VariableEnvironment("whose environment record holds bindings created by VariableStatements and FunctionDeclarations") stays unchanged.

console.log(a); // undefined - declared from within the catch,
                // but in the current VariableEnvironment
a = 1;
console.log(typeof ex); // undefined - no binding
try {
    console.log(ex); // a ReferenceError in this LexicalEnvironment
} catch (ex) { // introducing the new LexicalEnvironment
    console.log(ex); // …and it works here!
    var a = 3; // variable declaration
}

Fun fact: If you try to declare a function inside a catch clause (though syntactically invalid in a block, "function declaration statements" are often accepted), its scope will become the current VariableEnvironment so it will not be able to access the exception:

try {throw "some"} catch(x) { function y(){console.log(x, typeof x);} y(); }
                    // throws a ReferenceError for x   ^

_{(Update: this is no longer true in ES6, where block-level function declarations are valid and close over the block scope)}

Why do catch clauses have their own lexical environment?

Solution 1:

Related

Recent Posts