node/test/message/unhandled_promise_trace_war...

// Flags: --trace-warnings
'use strict';
require('../common');
const p = Promise.reject(new Error('This was rejected'));
setImmediate(() => p.catch(() => {}));
promise: better stack traces for --trace-warnings 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: https://github.com/nodejs/node/issues/9523 PR-URL: https://github.com/nodejs/node/pull/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> 2016-11-09 09:04:04 +08:00			`// Flags: --trace-warnings`
			`'use strict';`
test: remove common.noop This change removes `common.noop` from the Node.js internal testing common module. Over the last few weeks, I've grown to dislike the `common.noop` abstraction. First, new (and experienced) contributors are unaware of it and so it results in a large number of low-value nits on PRs. It also increases the number of things newcomers and infrequent contributors have to be aware of to be effective on the project. Second, it is confusing. Is it a singleton/property or a getter? Which should be expected? This can lead to subtle and hard-to-find bugs. (To my knowledge, none have landed on master. But I also think it's only a matter of time.) Third, the abstraction is low-value in my opinion. What does it really get us? A case could me made that it is without value at all. Lastly, and this is minor, but the abstraction is wordier than not using the abstraction. `common.noop` doesn't save anything over `() => {}`. So, I propose removing it. PR-URL: https://github.com/nodejs/node/pull/12822 Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Refael Ackermann <refack@gmail.com> 2017-05-04 12:07:54 +08:00			`require('../common');`
promise: better stack traces for --trace-warnings 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: https://github.com/nodejs/node/issues/9523 PR-URL: https://github.com/nodejs/node/pull/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> 2016-11-09 09:04:04 +08:00			`const p = Promise.reject(new Error('This was rejected'));`
test: remove common.noop This change removes `common.noop` from the Node.js internal testing common module. Over the last few weeks, I've grown to dislike the `common.noop` abstraction. First, new (and experienced) contributors are unaware of it and so it results in a large number of low-value nits on PRs. It also increases the number of things newcomers and infrequent contributors have to be aware of to be effective on the project. Second, it is confusing. Is it a singleton/property or a getter? Which should be expected? This can lead to subtle and hard-to-find bugs. (To my knowledge, none have landed on master. But I also think it's only a matter of time.) Third, the abstraction is low-value in my opinion. What does it really get us? A case could me made that it is without value at all. Lastly, and this is minor, but the abstraction is wordier than not using the abstraction. `common.noop` doesn't save anything over `() => {}`. So, I propose removing it. PR-URL: https://github.com/nodejs/node/pull/12822 Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Refael Ackermann <refack@gmail.com> 2017-05-04 12:07:54 +08:00			`setImmediate(() => p.catch(() => {}));`