Open rotu opened 3 months ago
It's reproducible via the VSCode debugger.
The debugger treats it as both a caught exception, and an uncaught exception.
It appears to be a debugger specific issue, as it does not emit an uncaughtException
(or unhandledRejection
) event on the process:
process.on("uncaughtException", () => console.log("uncaughtException")) // This is never called
process.on("unhandledRejection", () => console.log("unhandledRejection")) // This is never called
setTimeout(() => {
Promise
.reject("This is a promise rejection")
.catch(() => console.log("Caught promise rejection")) // This is called
}, 1)
It appears to be a debugger specific issue, as it does not emit an
uncaughtException
(orunhandledRejection
) event on the process:
Yes, it is a debugger-specific issue caused by V8 "catch prediction". The debugger breaks synchronously when the promise is rejected.
It would be okay if the debugger paused here when breakOnException
was specified, but it's inappropriate for breakOnUncaught
.
Related discussion: https://issues.chromium.org/issues/41161875
@nodejs/v8
Relatedly, the below code does not trip the debugger (with breakOnUncaught
enabled) and does not print anything. I think this situation is dual to the originally reported issue:
try
statement to apply to the rejection (it doesn't because the promise is never await
ed).setTimeout(async () => {
try {
Promise.reject()
} catch (e) { }
})
I think I figured out the setTimeout
part of this mystery. When running a module as the main entry point, the code is within in a try
block in an async
function (in module_job.js
).
Because of this try
/catch
block, NO promise rejection at module level is regarded by the inspector as an "uncaught exception", REGARDLESS OF WHETHER OR NOT IT HAS A HANDLER ATTACHED.
I raised an issue for this catch prediction false positive but it was regarded as "infeasible" here: https://issues.chromium.org/issues/352455689
When code escapes this call stack by running asynchronously, the inspector no longer regards it as handled by that try
/catch
so it may or may not be considered an "uncaught exception" (based on V8's designed behavior).
Here's a demonstration:
// assume this is in a .mjs file
// this function creates a Promise which is rejected and handled
// This promise is NOT regarded as "caught" by the V8's catch prediction
const makeRejectedPromise = (reason) => {
Promise.reject(reason).catch(() => {});
};
// rejection regarded as handled created synchronously:
makeRejectedPromise(1);
(async () => {
makeRejectedPromise(2);
})();
await null;
// or asynchronously after a module-level await
makeRejectedPromise(3);
// rejection regarded as unhandled when created asynchronously:
(async () => {
await null;
makeRejectedPromise(4);
})();
queueMicrotask(() => makeRejectedPromise(5));
process.nextTick(() => makeRejectedPromise(6));
setTimeout(() => makeRejectedPromise(7));
Version
v22.4.0
Platform
Subsystem
No response
What steps will reproduce the bug?
Create this script:
And run it in the debugger with
break on Uncaught
enabled.How often does it reproduce? Is there a required condition?
Every time. Note this does not happen if
Promise.reject()
is at top level instead of wrapped insetTimeout()
.What is the expected behavior? Why is that the expected behavior?
It is expected that the debugger does (1) not pause on such a promise or (2) only pauses on such a promise if
breakOnException
is enabled.The HTML spec guarantees that promise rejections are not considered unhandled if a handler is then synchronously attached.
What do you see instead?
Node breaks synchronously on the creation of the rejected promise. Similar issues happen when using the VSCode debugger and Chrome debugger.
Additional information
A downstream issue where this interferes with usage of the web streams API: #51093
I too have been incredibly confused by this, as it makes it seem like even correct usage of promises is developer error.
VSCode reports this as "Exception has occurred" instead of "promiseRejection".