You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Unhandled promise rejection when promise is not currently being await-ed on #4286
The following code will trigger an unhandled promise rejection.
Firefox has the same behavior.
Chrome however is interesting. At first Chrome console shows a red error but then Chrome changes its mind.
I'm just trying to understand why. I mean, logically it should work as the promise being rejected is eventually await-ed on later. But it seems like rejections must be await-ed on as they happen?
Node.js version
Not applicable.
Example code
(async()=>{try{constpromise=newPromise((resolve,reject)=>{reject(newError("oops"));});// Uncomment this to get a unhandled promise rejection.// await new Promise((resolve) => setTimeout(resolve, 1000)});awaitpromise;}catch(reason){console.log("caught the error");}})();
Operating system
Not applicable.
Scope
Not applicable.
Module and version
Not applicable.
Reactions are currently unavailable
Activity
ghost changed the title [-]Unhandled promise rejection when promise is not not currently being await-ed on[/-][+]Unhandled promise rejection when promise is not currently being await-ed on[/+]on Nov 6, 2023
In browsers, the console can be asynchronously updated; in node, it can not.
Promise unhandled rejection hooks were designed for (and really, only intended for use in) browsers, precisely because of this issue. Since node has chosen to implement these hooks, they will give false positives for a rejected promise that's handled later, and that's just unavoidable.
It’s a node issue, and yes, it’s a footgun. You can disable or change the unhandled rejection behavior with a flag, or by adding your own unhandled rejection event listener.
All browsers behave the same here, as the HTML spec requires it; the language spec merely allows implementations to do it (largely because there’s no good way to allow what browsers do while prohibiting what node does).
Activity
[-]Unhandled promise rejection when promise is not not currently being await-ed on[/-][+]Unhandled promise rejection when promise is not currently being await-ed on[/+]ljharb commentedon Nov 6, 2023
In browsers, the console can be asynchronously updated; in node, it can not.
Promise unhandled rejection hooks were designed for (and really, only intended for use in) browsers, precisely because of this issue. Since node has chosen to implement these hooks, they will give false positives for a rejected promise that's handled later, and that's just unavoidable.
ljharb commentedon Nov 7, 2023
It’s a node issue, and yes, it’s a footgun. You can disable or change the unhandled rejection behavior with a flag, or by adding your own unhandled rejection event listener.
All browsers behave the same here, as the HTML spec requires it; the language spec merely allows implementations to do it (largely because there’s no good way to allow what browsers do while prohibiting what node does).