promise: better stack traces for --trace-warnings by addaleax · Pull Request #9525 · nodejs/node

addaleax · 2016-11-09T01:17:51Z

Checklist

make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

Affected core subsystem(s)

promises

Description of change

Give better stack traces for PromiseRejectionHandledWarningand UnhandledPromiseRejectionWarnings.

For PromiseRejectionHandledWarning, when it is likely that there is an Error object generated, it is created early to provide a proper stack trace.

For UnhandledPromiseRejectionWarning, the stack trace of the
underlying error object is used, if possible.

Fixes: #9523

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: nodejs#9523

danbev · 2016-11-09T06:41:29Z

@@ -0,0 +1,4 @@
+// Flags: --trace-warnings
+'use strict';
+const p = Promise.reject(new Error('This was rejected'));


I think the common module needs to be required here:
require('../common');

@danbev right, done

mhdawson

LGTM as its seems like a good idea to me. Should it be tagged as a semver major though because it changes the stack trace that will be seen by the application ?

addaleax · 2016-11-09T22:43:19Z

@mhdawson Well… only if the application doesn’t use the unhandledRejection and rejectionHandled events, which are the programmatic API for these events. It is true that process.on('warning') handlers will receive different stack traces but I don’t know if that really counts as semver-major.

Marking this as a major might defeat the purpose of it, because I think the plan is to turn the warning into an error in the next (?) major release. I’m not sure about how exactly that would look like, though.

@nodejs/ctc Thoughts…?

addaleax · 2016-11-16T01:23:23Z

If nobody objects, I’d like to land this by Friday as a semver-patch change.

CI: https://ci.nodejs.org/job/node-test-commit/6020/

mhdawson · 2016-11-17T21:52:57Z

It would be nice to have a bit more input from ctc members on whether its ok to handle as a patch. @jasnell @bnoordhuis any opinion here.

jasnell · 2016-11-18T16:58:50Z

No objections to landing as a patch. Good change

addaleax · 2016-11-26T06:58:36Z

@mhdawson Would you be okay with this landing as a patch change? Is there any particular scenario that you are worried about?

targos

LGTM. +1 for considering it as a patch.

Fishrock123 · 2016-12-05T17:11:12Z

Oh wow, I just used trace --trace-warnings and rejected a promise and... that is definitely not useful currently.

This should be considered a bug fix, can we land it in v7.2.1 tomorrow?

addaleax · 2016-12-05T17:14:27Z

I’ll land it now, I think we basically have consensus on considering this semver-patch.

Fishrock123 · 2016-12-05T17:16:14Z

+function getAsynchronousRejectionWarningObject(uid) {
+ return new Error('Promise rejection was handled ' +
+ `asynchronously (rejection id: ${uid})`);
+}


Perhaps this could reduce late promise handling performance slightly but... oh well, maybe we can make that an option if people complain. ¯\_(ツ)_/¯ Good defaults are more important for this kind of thing.

Maybe, but I think it’s okay. This should not be a hot path anyway.

Fishrock123 · 2016-12-05T17:17:11Z

 promiseToGuidProperty.delete(promise);
 if (hasBeenNotified === true) {
+ let warning = null;
+ if (!process.listenerCount('rejectionHandled')) {


Won't this always be hit because of the default listener?

@Fishrock123 Are you referring to the code in the block below this one? That’s not technically a listener, so it isn’t counted here. Also, at least a quick check in the REPL yields process.listenerCount('rejectionHandled') === 0 by default.

addaleax · 2016-12-05T17:30:17Z

Landed in 196d27d

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: #9523 PR-URL: #9525 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>

Notable changes: * buffer: - Reverted the runtime deprecation of calling `Buffer()` without `new`. (Anna Henningsen) #9529 - Fixed `buffer.transcode()` for single-byte character encodings to `UCS2`. (Anna Henningsen) #9838 * promise: `--trace-warnings` now produces useful stacktraces for Promise warnings. (Anna Henningsen) #9525 * repl: Fixed a bug preventing correct parsing of generator functions. (Teddy Katz) #9852 * V8: Fixed a significant `instanceof` performance regression. (Franziska Hinkelmann) #9730 PR-URL: #10127

Notable changes: * buffer: - Reverted the runtime deprecation of calling `Buffer()` without `new`. (Anna Henningsen) nodejs/node#9529 - Fixed `buffer.transcode()` for single-byte character encodings to `UCS2`. (Anna Henningsen) nodejs/node#9838 * promise: `--trace-warnings` now produces useful stacktraces for Promise warnings. (Anna Henningsen) nodejs/node#9525 * repl: Fixed a bug preventing correct parsing of generator functions. (Teddy Katz) nodejs/node#9852 * V8: Fixed a significant `instanceof` performance regression. (Franziska Hinkelmann) nodejs/node#9730 Signed-off-by: Ilkka Myller <ilkka.myller@nodefield.com>

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: nodejs#9523 PR-URL: nodejs#9525 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>

MylesBorins · 2016-12-20T20:20:37Z

@addaleax should we land this on v6.x

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: nodejs#9523 PR-URL: nodejs#9525 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>

addaleax · 2016-12-21T06:10:56Z

backport @ #10378, we can discuss that there

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: #9523 PR-URL: #9525 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>

addaleax added promises Issues and PRs related to ECMAScript promises. dont-land-on-v4.x labels Nov 9, 2016

addaleax mentioned this pull request Nov 9, 2016
unhandledRejection Stack Traces are unhelpful #9523
Closed

bnoordhuis approved these changes Nov 9, 2016
View reviewed changes

danbev reviewed Nov 9, 2016
View reviewed changes

address nit
de662ae

danbev approved these changes Nov 9, 2016
View reviewed changes

mhdawson approved these changes Nov 9, 2016
View reviewed changes

cjihrig approved these changes Nov 11, 2016
View reviewed changes

jasnell approved these changes Nov 18, 2016
View reviewed changes

targos approved these changes Nov 27, 2016
View reviewed changes

Fishrock123 approved these changes Dec 5, 2016
View reviewed changes

addaleax closed this Dec 5, 2016

addaleax deleted the unhandled-promise-rejection-stack-trace branch December 5, 2016 17:30

MylesBorins added the lts-watch-v6.x label Dec 20, 2016

addaleax mentioned this pull request Dec 21, 2016
v6.x backport: promise: better stack traces for --trace-warnings #10378
Closed

addaleax added dont-land-on-v6.x and removed lts-watch-v6.x labels Dec 21, 2016

MylesBorins mentioned this pull request Jan 24, 2017
v6.10.0 proposal #10974
Merged

Uh oh!

Uh oh!

Conversation

addaleax commented Nov 9, 2016

Checklist

Affected core subsystem(s)

Description of change

Uh oh!

danbevNov 9, 2016

Choose a reason for hiding this comment

Uh oh!

addaleaxNov 9, 2016

Choose a reason for hiding this comment

Uh oh!

mhdawson left a comment

Choose a reason for hiding this comment

Uh oh!

addaleax commented Nov 9, 2016

Uh oh!

addaleax commented Nov 16, 2016

Uh oh!

mhdawson commented Nov 17, 2016

Uh oh!

jasnell commented Nov 18, 2016

Uh oh!

addaleax commented Nov 26, 2016

Uh oh!

targos left a comment

Choose a reason for hiding this comment

Uh oh!

Fishrock123 commented Dec 5, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

addaleax commented Dec 5, 2016

Uh oh!

Fishrock123Dec 5, 2016

Choose a reason for hiding this comment

Uh oh!

addaleaxDec 5, 2016

Choose a reason for hiding this comment

Uh oh!

Fishrock123Dec 5, 2016

Choose a reason for hiding this comment

Uh oh!

addaleaxDec 5, 2016

Choose a reason for hiding this comment

Uh oh!

addaleax commented Dec 5, 2016

Uh oh!

MylesBorins commented Dec 20, 2016

Uh oh!

addaleax commented Dec 21, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Fishrock123 commented Dec 5, 2016•
edited
Loading