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 <[email protected]> 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 > [email protected] > www.isiahmeadows.com > > On Sun, Sep 9, 2018 at 3:49 PM Peter Jaszkowiak <[email protected]> > 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 <[email protected]> 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 > >> [email protected] > >> www.isiahmeadows.com > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
