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

promises: improve unhandledrejection warnings #12982

Closed
wants to merge 3 commits into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented May 11, 2017

Per the CTC discussion around #12734 ...

This takes an alternative approach than #12734. Rather than adding a throw, it improves the warnings that are already there such that the stack trace for the rejection reason is always shown (assuming the reason is an Error object). It also adds a warning.reason property to the warning object emitted by process.on('warning'), allowing userland code to access the original error (and potentially throw if it wishes to do so).

other code cleanups were made while I was in there.

/cc @nodejs/ctc

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

promises

jasnell added 3 commits May 11, 2017 11:51
Use a linked list instead of an array for tracking
unhandled rejections. Using shift and push have had
some perf limitations in V8 lately. Using the linked
list approach avoids that issue and ensures constant
time adds and shifts.
* Set the warning.detail to reason.stack so the rejection stack is
  always printed (preserve the original warning.stack)
* Set the warning.reason property to the rejection reason
@mscdex mscdex added the promises Issues and PRs related to ECMAScript promises. label May 11, 2017
@Fishrock123
Copy link
Contributor

I don't think this is in anyway a replacement for my PRs, but ti seems like a tangentially good idea to expose the Promise's actual stack rather than the internals of where the error was "caught" at.

I'd rather just replace the current stack as exposed to --trace-warnings with the actual promise stack though...

@addaleax
Copy link
Member

The first 2 commits in here seem okay but not really related to the stack trace change itself?

Fwiw all that I had in mind when talking about this was basically turning --trace-warnings on by default for unhandled rejections.

@jasnell
Copy link
Member Author

jasnell commented May 15, 2017

Changing the --trace-warning output ends up completely hiding the fact that this is a warning in the stderr output. What you end up seeing is just an error stack. I'd rather not lose that context or have this type of error act differently than other types. I had missed the fact that it was changing the stack previously or I would have suggested this change before. With this change, we get a clear indication that it's a warning and the rejection stack trace. It's not clear at all how hiding the additional context is at all useful.

@mcollina
Copy link
Member

@jasnell can you add a test with two promise rejected? From what I expect, the stacktrace of the original error should get printed twice.

@mcollina
Copy link
Member

This is semver-major as it changes the output.

@mcollina mcollina added semver-major PRs that contain breaking changes and should be released in the next major version. notable-change PRs with changes that should be highlighted in changelogs. labels May 16, 2017
@mcollina
Copy link
Member

mcollina commented May 16, 2017

How would I use this in userland to crash if I have an unhandled rejection? I think we should cover this in a unit test maybe?

@jasnell
Copy link
Member Author

jasnell commented Jul 10, 2017

Will be returning to this PR this week. Hopeful to get it landed by end of week.

let lastPromiseId = 1;

exports.setup = setupPromises;
class RejectedList {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not simply class RejectedList extends Array { push(promise, reason) {super.push({promise, reason})} }?

@jasnell
Copy link
Member Author

jasnell commented Sep 12, 2017

Closing this due to lack of progress.

@jasnell jasnell closed this Sep 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
notable-change PRs with changes that should be highlighted in changelogs. promises Issues and PRs related to ECMAScript promises. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants