Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose the "enhanced" stack trace from uncaught exceptions to the uncaughtException and uncaughtExceptionMonitor handlers on process #55838

Open
danfuzz opened this issue Nov 13, 2024 · 1 comment
Labels
events Issues and PRs related to the events subsystem / EventEmitter. feature request Issues that request new features to be added to Node.js.

Comments

@danfuzz
Copy link

danfuzz commented Nov 13, 2024

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 uncaughtException handler on process in order to get uncaught exceptions written out to this logging system. I noticed that if there's no uncaughtException handler, 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 uncaughtException and uncaughtExceptionMonitor callbacks when an "enhanced" error is available, containing information corresponding to the site and target of the emit() call. It could, for example, be a plain object containing an Error representing 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 default uncaughtException handler prints out to the console:

process.on('uncaughtException', (err, origin, emitInfo) => {
  console.log('%s', err.stack);
  if (emitInfo) {
    const { emitter, emitSite } = emitInfo;
    console.log(`Emitted 'error' event of ${emitter.constructor.name} instance at:\n%s`,
      emitSite.stack);
  }
});

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.)

@danfuzz danfuzz added the feature request Issues that request new features to be added to Node.js. label Nov 13, 2024
@github-project-automation github-project-automation bot moved this to Awaiting Triage in Node.js feature requests Nov 13, 2024
@danfuzz
Copy link
Author

danfuzz commented Nov 13, 2024

Source reference for the current console behavior: https://github.com/nodejs/node/blob/main/lib/events.js#L422

@RedYetiDev RedYetiDev added the events Issues and PRs related to the events subsystem / EventEmitter. label Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
events Issues and PRs related to the events subsystem / EventEmitter. feature request Issues that request new features to be added to Node.js.
Projects
Status: Awaiting Triage
Development

No branches or pull requests

2 participants