-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
events: show throw stack trace for uncaught exception #19003
Conversation
lib/events.js
Outdated
@@ -98,6 +98,58 @@ EventEmitter.prototype.getMaxListeners = function getMaxListeners() { | |||
return $getMaxListeners(this); | |||
}; | |||
|
|||
// Returns the longest sequence of a that fully appears in b, of length >= 3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps use backticks around variables in these comments, otherwise 'a' looks like the article and not the variable and is confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, done.
I'm +1 on both the design choices (Only modifying if thrown, and removing duplicate lines). I'm wondering if this has a measurable performance impact. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice! I'd love some more tests - this is a nice improvement. I wonder how common creating the error in a different context from throw
ing it happens.
@benjamingr I would expect that if you write a benchmark that tests for it, it will show an impact. I wouldn’t include such a benchmark in our suite though; I don’t think creating a ton of I’ve also added more (but similar) tests, let me know if you had something specific in mind. |
lib/events.js
Outdated
} | ||
|
||
function enhanceStackTrace(err, own) { | ||
const sep = '\nEmitted \'error\' event at at:\n'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
duplicate "at"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lib/events.js
Outdated
} | ||
|
||
const kExpandStack = Symbol('kExpandStack'); | ||
Object.defineProperty(EventEmitter, 'kExpandStack', { value: kExpandStack }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is that made public on purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@targos It’s non-enumerable, so most people will never find out it exists… I don’t think anybody is going to use it? How would we hide it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it be exported by an internal module? Or is it too early in the bootstrapping process to do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@targos It’s fine, I’ve changes it – the worst case scenario is that this mechanism just doesn’t work and leaves the error unchanged.
dafe586
to
2d8e7ed
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add a test for process.on('uncaughtException', fn)
? I guess right now that does not work together?
lib/events.js
Outdated
return [ l1, j1, i1 ]; | ||
else | ||
return [ l2, i2, j2 ]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part confuses me. As far as I see it the common part will always be identical or do I miss something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BridgeAR Thanks for catching – it made sense in an earlier version of this code, but it’s removed now.
Show the stack trace for the `eventemitter.emit('error')` call in the case of an uncaught exception. Previously, there would be no clue in Node’s output about where the actual `throw` comes from.
It (intentionally) does not, yes, mostly to keep existing behavior unchanged & avoid this being semver-major. I don’t feel strongly about it, though. |
Landed in 68d508a |
Show the stack trace for the `eventemitter.emit('error')` call in the case of an uncaught exception. Previously, there would be no clue in Node’s output about where the actual `throw` comes from. PR-URL: #19003 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]>
Show the stack trace for the `eventemitter.emit('error')` call in the case of an uncaught exception. Previously, there would be no clue in Node’s output about where the actual `throw` comes from. PR-URL: nodejs#19003 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]>
Should this be backported to |
Show the stack trace for the `eventemitter.emit('error')` call in the case of an uncaught exception. Previously, there would be no clue in Node’s output about where the actual `throw` comes from. PR-URL: nodejs#19003 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]>
Show the stack trace for the
eventemitter.emit('error')
callin the case of an uncaught exception.
Previously, there would be no clue in Node’s output about where
the actual
throw
comes from.In its current form, this patch would not modify
err.stack
if the exception is handled somewhere, and it redacts lines from the throw stack trace if they are duplicates of the original error stack trace (which likely occurs a lot).Those design choices are up for debate :)
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
events