Repository navigation
Expose the "enhanced" stack trace from uncaught exceptions to the uncaughtException and uncaughtExceptionMonitor handlers on process #55838
Description
Activity
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Nov 13, 2024 Source reference for the current console behavior: https://github.com/nodejs/node/blob/main/lib/events.js#L422
- addedeventsIssues and PRs related to EventEmitter and the events module.Issues and PRs related to EventEmitter and the events module.
on Nov 13, 2024 github-actions commented
on May 13, 2025 on May 13, 2025 – with GitHub ActionsContributorMore actionsThere has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. 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.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on May 13, 2025 Commenting here to keep the issue open. I think this issue is worth addressing.
- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on May 14, 2025 github-actions commented
on Nov 10, 2025 on Nov 10, 2025 – with GitHub ActionsContributorMore actionsThere has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. 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.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Nov 10, 2025 Commenting here to keep the issue open. I think this issue is worth addressing.
- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Nov 11, 2025 This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jun 9, 2026 Commenting here to keep the issue open. I think this issue is worth addressing.
- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jun 11, 2026 I've opened a fix for this in #65580. Running
fatalExceptionStackEnhancers.beforeInspector(er)before emittinguncaughtExceptionMonitoranduncaughtExceptionensures that the enhanced stack trace (with the emitter call site) is accessible to handlers.Reacted by Dan Bornstein@santusht06 You're my hero.
Reacted by Santusht kotai
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsAwaiting Triage
What is the problem this feature will solve?
In my app, I have a logging system which writes entries to files and/or the network in a machine-parsable form. I use the
uncaughtExceptionhandler onprocessin order to get uncaught exceptions written out to this logging system. I noticed that if there's nouncaughtExceptionhandler, Node will print out an extra stack trace to the console indicating the call site of the<emitter>.emit('error', ...)call which emitted the ultimately-uncaught exception. However, it seems like there's no programmatic way for me to get that extra trace in my own handler.This feature will solve the problem of being able to programmatically extract this extra — and quite useful! — information in a way that works well with a system that eschews the console.
What is the feature you are proposing to solve the problem?
I don't know what tactic would work best within the larger Node ecosystem, but as a straw-man suggestion:
Add a third argument to the
uncaughtExceptionanduncaughtExceptionMonitorcallbacks when an "enhanced" error is available, containing information corresponding to the site and target of theemit()call. It could, for example, be a plain object containing anErrorrepresenting the call site and an object reference to the emitter itself. But if that's too dangerous, it might instead have strings representing that info. For example (in the former case), the following would nearly duplicate what the current defaultuncaughtExceptionhandler prints out to the console:What alternatives have you considered?
Having a separate process to scrape console output to find things that look like uncaught exceptions, so I can push them into the structured logging system. (Oof.)