Trigger `catch`/`finally` with rejected `return` promise in `async` functions
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?
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
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.
Does return foo not seemingly imply the implicit unwrapping is
occuring inside the function?
Note as well that
return awaitintroduces 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
Le 9 sept. 2018 à 23:49, Isiah Meadows <isiahmeadows at gmail.com> a écrit :
Does
return foonot 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.”
I know this requires a bit of an exception, but I feel
catch/finallyshould trigger when a promisereturned from anasyncfunction 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 viatry/catch, even if it's a simplereturn foo(...args). You see that a lot with thereturn await foo(...args)step necessary withintry/catchblocks in async functions, but that's literally the only time that idiom is necessary - it's otherwise generally equivalent toreturn 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