Feature request: uncaughtExceptionMonitor to differentiate if the origin is an EventEmitter
What is the problem this feature will solve?
It is currently not straightforward to know if an uncaughtException originated from an EventEmitter that emitted an error event without any attached listener or from somewhere else. Making the distinction and providing the emitter itself in a similar fashion to providing the rejected promise in unhandledRejection events would help with debugging.
What is the feature you are proposing to solve the problem?
A new origin for both uncaughtException and uncaughtExceptionMonitor events:
-
uncaughtException -
unhandledRejection -
unhandledErrorEvent(name can be discussed)
Similar to https://github.com/nodejs/node/issues/51201, we could have
process.on('uncaughtExceptionMonitor', (err, origin, details) => {
if (origin === 'unhandledRejection') {
// details is the rejected promise.
} else if (origin === 'unhandledErrorEvent') {
// details is the EventEmitter that emitted an `error` event.
} else {
// details is something else or undefined.
}
});
Having the stack trace of the creation of the EventEmitter would be helpful in debugging as well but expensive as my understanding of https://github.com/nodejs/node/issues/39917
What alternatives have you considered?
No response
I can work on this one
This could be considered a breaking change, as long as not all the exceptions are handled as they used to; if that happens, code relying on events will need to modify their error handling mechanism.
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the https://github.com/nodejs/node/labels/never-stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document.
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.