Re: Promises: unhandled rejections and finally()

2020-03-28 Thread Jordan Harband
It does pass through the fulfillment status - but it does that by adding
both an onFulfilled and an onRejected handler, so it does affect the
"unhandled rejection" hook.

On Sat, Mar 28, 2020 at 7:23 PM Felipe Gasper 
wrote:

> Hi Logan,
>
> Thank you .. that makes sense. I’m not sure why now but I had in mind that
> finally() creates a “passthrough” promise that doesn’t affect its parent
> promise’s resolved/rejected status.
>
> Cheers,
> -Felipe
>
> On Mar 28, 2020, at 21:40, Logan Smyth  wrote:
>
> 
> > Could someone point me to something that would help me to understand the
> logic here? It looks like the first finally() is getting a “free pass”
> while only the 2nd and subsequent ones trigger their own
> unhandled-rejection warnings.
>
> I think the best place to start in understanding this would be to step
> back and make sure you understand what it is that triggers these errors.
> Node triggers these errors when a promise object has been rejected but has
> no handlers to do respond to the rejection. I forget exactly what point
> Node checks for handlers these days, if that point is at the end of the job
> execution or on GC of promises now or what but that's not important for
> this case.
>
> Let's look at your example. I'm also simplifying it to
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> var two = p.finally(() => {});
> var three = p.finally(() => {});
> ```
>
> 1)
> ```
> var p = Promise.reject(789);
> ```
> There is only one promise here, `p`, and it has no handlers ever attached
> to it so there is nothing to handle the rejection error, hence the single
> uncaught rejection error.
>
> 2)
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> ```
> There are 2 promises here, `p`, which has one handler (the `finally` that
> will take the rejection of `p` and in turn reject `one`) and `one`, which
> has no handlers attached, so you again get a single uncaught rejection. It
> as not that the first "finally" gets a "free pass", it is that rejections
> from `p` are no longer uncaught, but you have added a new promise that is
> uncaught, so the overall number of uncaught rejections does not change.
>
> 3)
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> var two = p.finally(() => {});
> ```
> Hopefully you can see where this is going. `p` now has 2 handlers attached
> so its rejection isn't uncaught, but now both `one` and `two` have no
> handlers, so _both_ will trigger an uncaught rejection error.
>
> 4)
> ```
> var p = Promise.reject(789);
> var one = p.finally(() => {});
> var two = p.finally(() => {});
> var three = p.finally(() => {});
> ```
> And finally now we have `one`, `two` and `three` all with no handlers
> attached, so you will get three uncaught rejection errors.
>
> Hope that helps!
>
>
> On Sun, Mar 29, 2020 at 9:03 AM Felipe Gasper 
> wrote:
>
>> Hello,
>>
>> In node 12 as well as the latest Chrome and FF (all on macOS) I see the
>> following:
>>
>> -
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); n(789);
>> ==> produces 1 unhandled-rejection warning
>>
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( ()
>> => {} ); n(789);
>> ==> produces 1 unhandled-rejection warning
>>
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( ()
>> => {} ); p.finally( () => {} ); n(789);
>> ==> produces 2 unhandled-rejection warnings
>>
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( ()
>> => {} ); p.finally( () => {} ); p.finally( () => {} ); n(789);
>> ==> produces 3 unhandled-rejection warnings
>>
>> -
>>
>> Could someone point me to something that would help me to understand the
>> logic here? It looks like the first finally() is getting a “free pass”
>> while only the 2nd and subsequent ones trigger their own
>> unhandled-rejection warnings.
>>
>> Thank you!
>>
>> cheers,
>> -Felipe Gasper
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Promises: unhandled rejections and finally()

2020-03-28 Thread Felipe Gasper
Hi Logan,

Thank you .. that makes sense. I’m not sure why now but I had in mind that 
finally() creates a “passthrough” promise that doesn’t affect its parent 
promise’s resolved/rejected status.

Cheers,
-Felipe

> On Mar 28, 2020, at 21:40, Logan Smyth  wrote:
> 
> 
> > Could someone point me to something that would help me to understand the 
> > logic here? It looks like the first finally() is getting a “free pass” 
> > while only the 2nd and subsequent ones trigger their own 
> > unhandled-rejection warnings.
> 
> I think the best place to start in understanding this would be to step back 
> and make sure you understand what it is that triggers these errors. Node 
> triggers these errors when a promise object has been rejected but has no 
> handlers to do respond to the rejection. I forget exactly what point Node 
> checks for handlers these days, if that point is at the end of the job 
> execution or on GC of promises now or what but that's not important for this 
> case. 
> 
> Let's look at your example. I'm also simplifying it to
> ```
> var p = Promise.reject(789); 
> var one = p.finally(() => {}); 
> var two = p.finally(() => {}); 
> var three = p.finally(() => {});
> ```
> 
> 1)
> ```
> var p = Promise.reject(789);
> ```
> There is only one promise here, `p`, and it has no handlers ever attached to 
> it so there is nothing to handle the rejection error, hence the single 
> uncaught rejection error.
> 
> 2) 
> ```
> var p = Promise.reject(789); 
> var one = p.finally(() => {});
> ```
> There are 2 promises here, `p`, which has one handler (the `finally` that 
> will take the rejection of `p` and in turn reject `one`) and `one`, which has 
> no handlers attached, so you again get a single uncaught rejection. It as not 
> that the first "finally" gets a "free pass", it is that rejections from `p` 
> are no longer uncaught, but you have added a new promise that is uncaught, so 
> the overall number of uncaught rejections does not change.
> 
> 3)
> ```
> var p = Promise.reject(789); 
> var one = p.finally(() => {}); 
> var two = p.finally(() => {});
> ```
> Hopefully you can see where this is going. `p` now has 2 handlers attached so 
> its rejection isn't uncaught, but now both `one` and `two` have no handlers, 
> so _both_ will trigger an uncaught rejection error.
> 
> 4)
> ```
> var p = Promise.reject(789); 
> var one = p.finally(() => {}); 
> var two = p.finally(() => {});
> var three = p.finally(() => {});
> ```
> And finally now we have `one`, `two` and `three` all with no handlers 
> attached, so you will get three uncaught rejection errors.
> 
> Hope that helps!
> 
> 
>> On Sun, Mar 29, 2020 at 9:03 AM Felipe Gasper  
>> wrote:
>> Hello,
>> 
>> In node 12 as well as the latest Chrome and FF (all on macOS) I see the 
>> following:
>> 
>> -
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); n(789);
>> ==> produces 1 unhandled-rejection warning
>> 
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () => 
>> {} ); n(789);
>> ==> produces 1 unhandled-rejection warning
>> 
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () => 
>> {} ); p.finally( () => {} ); n(789);
>> ==> produces 2 unhandled-rejection warnings
>> 
>> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () => 
>> {} ); p.finally( () => {} ); p.finally( () => {} ); n(789);
>> ==> produces 3 unhandled-rejection warnings
>> 
>> -
>> 
>> Could someone point me to something that would help me to understand the 
>> logic here? It looks like the first finally() is getting a “free pass” while 
>> only the 2nd and subsequent ones trigger their own unhandled-rejection 
>> warnings.
>> 
>> Thank you!
>> 
>> cheers,
>> -Felipe Gasper
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: Promises: unhandled rejections and finally()

2020-03-28 Thread Logan Smyth
> Could someone point me to something that would help me to understand the
logic here? It looks like the first finally() is getting a “free pass”
while only the 2nd and subsequent ones trigger their own
unhandled-rejection warnings.

I think the best place to start in understanding this would be to step back
and make sure you understand what it is that triggers these errors. Node
triggers these errors when a promise object has been rejected but has no
handlers to do respond to the rejection. I forget exactly what point Node
checks for handlers these days, if that point is at the end of the job
execution or on GC of promises now or what but that's not important for
this case.

Let's look at your example. I'm also simplifying it to
```
var p = Promise.reject(789);
var one = p.finally(() => {});
var two = p.finally(() => {});
var three = p.finally(() => {});
```

1)
```
var p = Promise.reject(789);
```
There is only one promise here, `p`, and it has no handlers ever attached
to it so there is nothing to handle the rejection error, hence the single
uncaught rejection error.

2)
```
var p = Promise.reject(789);
var one = p.finally(() => {});
```
There are 2 promises here, `p`, which has one handler (the `finally` that
will take the rejection of `p` and in turn reject `one`) and `one`, which
has no handlers attached, so you again get a single uncaught rejection. It
as not that the first "finally" gets a "free pass", it is that rejections
from `p` are no longer uncaught, but you have added a new promise that is
uncaught, so the overall number of uncaught rejections does not change.

3)
```
var p = Promise.reject(789);
var one = p.finally(() => {});
var two = p.finally(() => {});
```
Hopefully you can see where this is going. `p` now has 2 handlers attached
so its rejection isn't uncaught, but now both `one` and `two` have no
handlers, so _both_ will trigger an uncaught rejection error.

4)
```
var p = Promise.reject(789);
var one = p.finally(() => {});
var two = p.finally(() => {});
var three = p.finally(() => {});
```
And finally now we have `one`, `two` and `three` all with no handlers
attached, so you will get three uncaught rejection errors.

Hope that helps!


On Sun, Mar 29, 2020 at 9:03 AM Felipe Gasper 
wrote:

> Hello,
>
> In node 12 as well as the latest Chrome and FF (all on macOS) I see the
> following:
>
> -
> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); n(789);
> ==> produces 1 unhandled-rejection warning
>
> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( ()
> => {} ); n(789);
> ==> produces 1 unhandled-rejection warning
>
> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( ()
> => {} ); p.finally( () => {} ); n(789);
> ==> produces 2 unhandled-rejection warnings
>
> var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( ()
> => {} ); p.finally( () => {} ); p.finally( () => {} ); n(789);
> ==> produces 3 unhandled-rejection warnings
>
> -
>
> Could someone point me to something that would help me to understand the
> logic here? It looks like the first finally() is getting a “free pass”
> while only the 2nd and subsequent ones trigger their own
> unhandled-rejection warnings.
>
> Thank you!
>
> cheers,
> -Felipe Gasper
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss