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

Isiah Meadows isiahmeadows at gmail.com
Sun Sep 9 21:49:42 UTC 2018


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
On Sun, Sep 9, 2018 at 5:45 PM Jordan Harband <ljharb at gmail.com> wrote:
>
> 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
>
>


More information about the es-discuss mailing list