Discuss
  • Why is `catch` a [reserved] keyword?

Why is `catch` a [reserved] keyword?

# Jeff Morrison (11 years ago)

I was just talking with a co-worker today about why it's ok for 'catch' to be a property name, but not a variable identifier. It's clear that the reasoning here is because property names aren't restricted by reserved words, but it's unclear why 'catch' must be reserved to begin with?

I had always assumed that keywords are reserved for syntax ambiguity reasons...but when I think about it I can't come up with any scenarios where a hypothetical 'catch' variable could be ambiguous with a catch block... What am I missing?

Since try blocks must always be followed by either a catch-block, a finally-block, or catch-then-finally it seems it's always easily possible to distinguish a catch block from a function-call + empty-block:

// Never an ASI concern because try is followed by catch
try { stuff(); }
catch(e) {}

// Not valid, so it's not possible to confuse this with try-finally + 
call + empty block
try { stuff(); }
finally { }
catch (e) {}
# C. Scott Ananian (11 years ago)

My guess would be that catch is reserved so that (in a future version of JavaScript) this won't be ambiguous:

try { stuff(); }
catch(e1) { }
catch(e2) { }

Currently JS only allows a single catch clause. But if it ever grows guarded catch expressions, then you would want to add multiple catch clauses. All but the first could potentially be ambiguous with an invocation of a function named catch.

# Jeff Morrison (11 years ago)

That's a great point, thanks.

# Dmitry Soshnikov (11 years ago)

FWIW: some implementations (e.g. SpiderMonkey) has this approach for years, using guards:

try { throw 1; }
catch (e if (e instanceof TypeError)) { console.log(e); }
catch (e) { console.log('Generic handler:', e); }