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

Isiah Meadows isiahmeadows at
Sun Sep 9 20:35:22 UTC 2018

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`

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



Isiah Meadows
contact at

On Sun, Sep 9, 2018 at 3:49 PM Peter Jaszkowiak <p.jaszkow at> 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> 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
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

More information about the es-discuss mailing list