Discussion: optional catch binding

[Inve1951]

I just stumbled upon this: https://github.com/tc39/proposal-optional-catch-binding It's a stage 4 proposal which allows js code like

try {
  // ...
} catch {
  // ...
}

Input Code

try obj = JSON.parse '{"a": "1"}'
console.log obj ? "failed to parse json"

Current Behavior

var obj;

try {
  obj = JSON.parse('{"a": "1"}');
} catch (error) {}

console.log(obj != null ? obj : "failed to parse json");

New Behavior

var obj;

try {
  obj = JSON.parse('{"a": "1"}');
} catch {}

console.log(obj != null ? obj : "failed to parse json");

Support already looks good too: https://caniuse.com/#feat=mdn-javascript_statements_try_catch_optional_catch_binding https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch#Browser_compatibility

Just dropping this here so it can be looked at whether or not this should be output by CoffeeScript.

[GeoffreyBooth]

Part of CoffeeScript 2 was updating our output to use modern standards whenever possible and equivalent, like outputting => for =>, for example. That’s still something we want to do, so in that vein yes, this is something we want to adopt; but the question is when.

With CoffeeScript 2 we took the approach of putting big warnings in the docs for any modern syntax we were outputting that active (not end-of-life) versions of Node didn’t support. Most prominent of these were the warnings for import/export and object spread syntax. We didn’t include warnings for browsers because frontend developers are used to needing to confirm that the features they want to use are supported in the browsers they’re targeting.

So we can do that again for this, but, is this feature really worth it? Does it provide any benefit beyond cleaner output JavaScript, and are the benefits worth people needing to add Babel transpilation when they otherwise might not have needed to, or be conscious of avoiding using this feature if it’s unsupported in whatever runtime(s) they’re targeting? At this point the only gotcha syntax developers need to be aware of (assuming they’re developing for modern Node and evergreen browsers) is import/export, and that’s coming to Node soon. Users really don’t like these exceptions; we got a few complaints about object spread while we were outputting that and before Node supported it.

The safest approach, therefore, is to add support for this at least after the current version Node has added support for it (maybe it already has?) and possibly after the oldest LTS version of Node also supports it, which could be a few years from now. That’s not very satisfying, I realize. But I think that should probably be our baseline assumption for new features that offer no improvements on the CoffeeScript side, like in this case: the CoffeeScript you write doesn’t change, only the JavaScript output gets a bit cleaner. That is its own benefit in that things are easier to debug, but that’s a very minor benefit when weighed against needing to add this to the list of things in the docs that could be gotchas for users to be aware of (and ideally we want at least Node developers to not need to transpile, rather than giving them more reasons why Babel is necessary).

I think the same logic applies to optional chaining and the nullish coalescing operator, which I think both just a few weeks ago also reached Stage 4. I haven’t studied the ES versions in detail, but if they behave identically or nearly identically to the CoffeeScript equivalents that inspired them, then similarly to => the only benefit we have to updating our output to use these new syntaxes is prettier output. Which is its own improvement, sure, but not at the expense of compatibility headaches.

All that said, if there are benefits beyond prettier output, then absolutely we should look into supporting all these features sooner than whenever the oldest Node LTS finally supports them.

[Inve1951]

My thoughts exactly.

Current LTS (v10) does support it. Node v8 (previous LTS release) is still maintained until 2019-12-31 (which is only 10 more weeks).