> Le 9 sept. 2018 à 23:49, Isiah Meadows a écrit :
>
> Does `return foo` not 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
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`
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
wrote:
> Yes, and I
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
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 wrote:
> I know this requires
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
6 matches
Mail list logo
