Trigger `catch`/`finally` with rejected `return` promise in `async` functions

# Isiah Meadows (10 days ago)

I know this requires a bit of an exception, but I feel catch/finally should trigger when a promise returned from an async function rejects. It just seems incredibly odd not to, since the usual intuition is that if an error occurs during the execution of a function, it's catchable by the parent via try/catch, even if it's a simple return foo(...args). You see that a lot with the return await foo(...args) step necessary within try/catch blocks in async functions, but that's literally the only time that idiom is necessary - it's otherwise generally equivalent to return foo(...args) mod timings, including when returning directly outside them.

Could you all in TC39 fix this to work a little more intuitively?


Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Peter Jaszkowiak (10 days ago)

So are you saying that return promise and return await promise should have identical behavior in the context of an async function?

Wouldn't that be a breaking change? And isn't it trivially solvable with a linter rule?

# Isiah Meadows (10 days ago)

Yes, and I know it's a breaking change. And although ESLint does have a rule banning return await 1, they did have to fix it to account for the fact "fixing" the inconsistency breaks try/catch/finally 2.

I'm specifically proposing it to avoid the counterintuitive behavior that currently exists in that area, why the lint had to make the exception in the first place.

I'm not familiar with a linter rule that addresses this issue, but it still reads very awkwardly when it works as advertised everywhere else.


Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Jordan Harband (10 days ago)

I think the explicit await, indicating you want to handle it in the async function, is a much better way to do it.

Note as well that return await introduces extra ticks, potentially slowing down your code unnecessarily.

# Isiah Meadows (10 days ago)

Does return foo not seemingly imply the implicit unwrapping is occuring inside the function?

Note as well that return await introduces extra ticks, potentially slowing down your code unnecessarily.

I'm aware. BTW, it's not like the implicit return inside try/catch/finally couldn't invoke .then manually to dodge the tick penalty, and that's basically what I'm proposing.


Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Claude Pache (10 days ago)

Le 9 sept. 2018 à 23:49, Isiah Meadows <isiahmeadows at gmail.com> a écrit :

Does return foo not seemingly imply the implicit unwrapping is occuring inside the function?

For me, no. If I want to await the resolution of the promise foo before handling the catch or the finally block, I expect to add an explicit await.

”Intuition” may vary among people. I think that, in general, it is better to use the more objective notion of ”regularity”, which is, in this case: ”Always use an explicit await (or Promise.all, etc.) if, at this point of the program, you want to await the resolution.”