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

Jordan Harband ljharb at gmail.com
Sun Sep 9 21:44:39 UTC 2018


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.

On Sun, Sep 9, 2018 at 1:35 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> 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.
>
> [1]: https://eslint.org/docs/rules/no-return-await
> [2]: https://github.com/eslint/eslint/issues/7581
>
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
>
> On Sun, Sep 9, 2018 at 3:49 PM Peter Jaszkowiak <p.jaszkow at gmail.com>
> wrote:
> >
> > 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?
> >
> > On Sun, Sep 9, 2018, 13:29 Isiah Meadows <isiahmeadows at gmail.com> wrote:
> >>
> >> I know this requires a bit of an exception, but I feel
> >> `catch`/`finally` should trigger when a promise `return`ed 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
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180909/acffd2f2/attachment-0001.html>


More information about the es-discuss mailing list