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

promise: Add --throw-unhandled-rejection and --trace-unhandled-rejection #6355

Conversation

yosuke-furukawa
Copy link
Member

@yosuke-furukawa yosuke-furukawa commented Apr 23, 2016

Checklist
  • tests and code linting passes
  • a test and/or benchmark is included
  • documentation is changed or added
  • the commit message follows commit guidelines
Affected core subsystem(s)

promise

Description of change

We are writing a lots of Promise modules and test these modules in our development environment. When process.on('unhandledRejection') error is occurred, default node behavior does not send any message, no warnings, no exceptions. So we have to prepare the following code and add tests.

process.on('unhandledRejection', (reason) => {
  throw reason;
});

This is not so easy for Promise / Node beginner. So I would like to propose the following 2 options.

  1. --throw-unhandled-rejection option will throw Exception when no unhandledRejection listener
  2. --trace-unhandled-rejection option will output stderr when no unhandledRejection listener

I know the default unhandledRejection behavior is discussing here
nodejs/promises#26

But I would like to add these options to help our developments.

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Apr 23, 2016
@addaleax addaleax added the promises Issues and PRs related to ECMAScript promises. label Apr 23, 2016
if (process.argv[2] === 'child') {
const rejectPromise = () => {
return new Promise((resolve, reject) => {
setTimeout(reject(new Error('Reject Promise')), 100);
Copy link
Member

Choose a reason for hiding this comment

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

If you want to have the reject() call delayed, you need to wrap it in a closure, i.e. setTimeout(() => reject(new Error('Reject Promise')), 100);. Right now, the whole child block is equivalent to Promise.reject(new Error('Reject Promise')).

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, I fixed it.

@Fishrock123 Fishrock123 added the semver-minor PRs that contain new features and should be released in the next minor version. label Apr 23, 2016
@ChALkeR
Copy link
Member

ChALkeR commented Apr 24, 2016

/cc @benjamingr

…ion option

--throw-unhandled-rejection option can throw Exception when no
unhandledRejection listener

--trace-unhandled-rejection option can output error on stderr
when no unhandledRejection listener
@yosuke-furukawa yosuke-furukawa force-pushed the feature/promise/throw-error-unhandled-rejection branch from bedb1aa to 580ca38 Compare April 24, 2016 09:08
@benjamingr
Copy link
Member

I'm -1 on this change.

We should not be adding flags for these things - the reason we have an "abort on uncaught exceptions" flag is because of core dumps.

What we should be doing is defaulting to logging these errors rather than silently swallowing them - like browsers and other languages do.

@Fishrock123
Copy link
Contributor

Fishrock123 commented Apr 24, 2016

Don't throws have the same stacktrace?

The behavior should really just throw by default as I have mentioned before. Ideally after checking in a more deterministic way. (e.g. GC)

In lieu of that, logging could be fine. I won't be able to finish the GC idea for v6, that's for sure.

@benjamingr
Copy link
Member

@Fishrock123 great, can we maybe bring logging by default to a vote and can I count on your vote with the caveat that we can might instead throw on GC collection?

@yosuke-furukawa
Copy link
Member Author

@benjamingr @Fishrock123
Logging by default is enough for my situation.
I am preparing to send a next PR, here.

https://github.com/nodejs/node/compare/master...yosuke-furukawa:promise-logging-default-unhandled-rejection?expand=1

If no one has a strong objection to logging messages, I will close this PR and send next PR.

@Fishrock123
Copy link
Contributor

I'm getting the GC and processes end handlers working. Standby..

@Fishrock123
Copy link
Contributor

Updated #5292 ... still working on one last point. PTAL.

@Fishrock123
Copy link
Contributor

#6375 should probably supersede this.

Fishrock123 added a commit to Fishrock123/node that referenced this pull request Apr 25, 2016
@yosuke-furukawa
Copy link
Member Author

I think my PR is finished its role, some following PRs are created and discussion is started, so I close this PR.
#6439
#6375

Fishrock123 added a commit to Fishrock123/node that referenced this pull request Feb 10, 2017
Fishrock123 added a commit to Fishrock123/node that referenced this pull request Apr 28, 2017
Fishrock123 added a commit to Fishrock123/node that referenced this pull request Apr 28, 2017
BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Sep 26, 2017
src: use std::map for the promise reject map

Refs: nodejs#5292
Refs: nodejs/promises#26
Refs: nodejs#6355
Refs: nodejs#6375
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. promises Issues and PRs related to ECMAScript promises. semver-minor PRs that contain new features and should be released in the next minor version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants