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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-2
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
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Peter Jaszkowiak
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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-2
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
[hidden email]
www.isiahmeadows.com

On Sun, Sep 9, 2018 at 3:49 PM Peter Jaszkowiak <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> www.isiahmeadows.com
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jordan Harband
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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com

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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-2
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
[hidden email]
www.isiahmeadows.com
On Sun, Sep 9, 2018 at 5:45 PM Jordan Harband <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> www.isiahmeadows.com
>>
>> On Sun, Sep 9, 2018 at 3:49 PM Peter Jaszkowiak <[hidden email]> 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 <[hidden email]> 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
>> >> [hidden email]
>> >> www.isiahmeadows.com
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> [hidden email]
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Claude Pache


> Le 9 sept. 2018 à 23:49, Isiah Meadows <[hidden email]> 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 explicit `await`.

”Intuition” may vary among people. I think that, in general, it is better to use the more objective notion of ”regularity”, which is, in this case: ”Always use an explicit `await` (or `Promise.all`, etc.) if, at this point of the program, you want to await the resolution.”

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss