JS MAY (behave differently on different runtime) not catch the rejected promise in setTimeout-CodePudding

In the following code.

const p = Promise.reject();;
setTimeout(() => {
    p.catch(() => console.log("Error caught"));
}, 0);

I expected Error caught is printed, but when I run it in Node v16.15.1, it crashes with UnhandledPromiseRejection error.

node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "undefined".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

The error is not caught.

Then I tried in chrome 102.0.5005.63 but I got Error caught printed as expected.

Now I'm very confused about this behavior.

CodePudding user response：

There must be at least one rejection handler attached to a Promise at the moment that the Promise rejects to avoid unhandled rejections. The Promise will have rejected (and the error will have been generated) by the time the timeout callback runs.

Your code produces an unhandled rejection in Chrome as well, as expected - add an unhandledrejection listener to see (though, of course, unlike Node, this doesn't crash the page)

window.addEventListener('unhandledrejection', () => {
  console.log('Unhandled rejection detected');
});
const p = Promise.reject();;
setTimeout(() => {
    p.catch(() => console.log("Error caught"));
}, 0);

Adding a .catch after the Promise has rejected will result in the .catch handler running - but the engine will already have seen that at the moment the Promise rejected, the rejection wasn't handled.

Best approach to this sort of thing - add a .catch handler synchronously when the Promise is created, not after any possible asynchronous action, otherwise the Promise might reject before the handler gets attached.