Optional Catch Binding (Stage 4)

[bakkot]

Champion: @michaelficarra
Spec repo: https://github.com/michaelficarra/optional-catch-binding-proposal/
Spec text: https://michaelficarra.github.io/optional-catch-binding-proposal/
Stage: -1 :)

Moved to Stage 3 at the July meeting https://github.com/tc39/agendas/blob/master/2017/07.md

Stage 4 at May 2018 meeting

This hasn't been presented to the committee as of this writing, but will be at the July meeting. If it receives broad support it is likely to advance quickly, in my personal estimation.

It allows the binding to be omitted from a catch clause:

try {
  throw 0;
} catch {
  doSomethingWhichDoesntCareAboutTheValueThrown();
}

or

try {
  throw 0;
} catch {
  doSomethingWhichDoesntCareAboutTheValueThrown();
} finally {
  doSomeCleanup();
}

This will need a (very small) change in Babylon, including a change to the AST (marking the catch binding as optional), and then a very small change to Babel.

This would make a great first contribution, I think!

UPDATE:

• Babylon PR - Add optionality to catch bindings babylon#634
• Babel PR - Add optionality to catch bindings babel#5956

[bakkot]

Note that you may want to hold off work until after the July TC39 meeting, in case this gets shot down.

J/k you should do it now :)

[michaelficarra]

Nah, this proposal's just going to glide right through to stage 4 as-is. Send in your PRs!

[MarckK]

Hi, I'd be quite happy to work on this :)

[xtuc]

@MarckK good news 👍 . Don't hesitate to ping us on Slack if you need help.

[reaktivo]

What do you think of making the catch block optional?

[ljharb]

just try { }?

See https://twitter.com/ljharb/status/861992651423227904 for a related thread.

[reaktivo]

Yes, seems like the thread supported it. It's useful in cases like the following:

const safeParseJson = (str) => {
  try {
    return JSON.parse(str);
  } catch (e) {}
}

When you actually wanted undefined to be returned. I wish do try would work without brackets.

const safeParseJson = str => do try { JSON.parse(str) };

[hzoo]

babel/babylon#634 is merged, will do a release so the transform can use it

[existentialism]

babel/babel#5956 (comment) has also been merged

[hzoo]

Released in https://github.com/babel/babel/releases/tag/v7.0.0-alpha.17 via babel-plugin-transform-optional-catch-binding

Input

try {
  throw 0;
} catch {
  console.log("it failed, but this code executes");
}

Output

try {
  throw 0;
} catch (_unused) {
  console.log("it failed, but this code executes");
}

[jridgewell]

@MarckK: Want to submit a change to babel-preset-stage-3 to include optional catch binding? Other than that, we can close this proposal.

[hzoo]

@existentialism did this in babel/babel#6032 (Stage 3)

Can add to the readme now though.

When should we close (was thinking when its Stage 4)

https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-optional-catch-binding

[pronebird]

Sorry if a little bit out of context but the comment by @reaktivo looks really appealing to me.

Maybe this transform wouldn't be needed at all then because not catching errors is a bad practice anyway but if there is the case then maybe it's better to do it differently.

Maybe something like try? or do try or any kind of that stuff could be adopted:

const isTheFeatureImplemented = try? doSomethingThatThrows(); // either result or undefined

or

const isTheFeatureImplemented = try doSomethingThatThrows() catch(e) {
  return 'sayonara'; // quit the scope cuz it's game over
};

Currently this is a big PITA of using exception because there are no guard statements that we could easily use to try or bail.

So what I see is we get a bunch of let+try+catch uses, then everything has to be mutable or need to do const reassignment or any other kind of voodoo.

The other malice practice is people simply wrap all kind of code into one huge try+catch and do everything inside of the try block which is not optimal esp. given that error handling in Javascript is quite infantile.

[ljharb]

Optional catch binding is stage 3; this transform is needed regardedless.

[licg9999]

Hi, would you think about try..finally syntax? In react-dom there is such usage. If you can handle it, you could make react-dom runnable in Edge and old IE.

// input
try{
  doSomeThing();
}finally{
  cleanUp();
}

// output
try{
  doSomeThing();
}catch(e){
}finally{
  cleanUp();
}

[ljharb]

@licg9999 try and finally by itself is already legal, but if you don't have a catch it will throw.

[licg9999]

Oh, sorry for my misunderstanding... Error in my case is promise.finally not found, I mistook. Thanks for your warm hint.