-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
process: Change default --unhandled-rejections=warn-with-error-code #33033
Conversation
When I posted this PR, I hadn't yet seen @BridgeAR's comment #33021 (comment):
Well, the work is done, and I figure it's better to have the code out there while we wait for results. |
needs another 6 |
8ae28ff
to
2935f72
Compare
This is a semver-major change that resolves DEP0018. In addition to changing the default value for --unhandled-rejections, this PR changes the exit code from 1 to 66. The warning message has been updated to mention the new exit code, which I selected in order to make this problem easier to search for on the web. Users can prevent this behavior by setting a non-default value for the --unhandled-rejections flag (throw, strict, warn, or none) or by setting a hook for 'unhandledRejection'. This change has no effect on users who have already set the flag or installed an 'unhandledRejection' hook; it will only impact users who currently see a DEP0018 warning today.
d96a83b
to
e46e34b
Compare
That's what this PR does, right? Why would anyone want this behavior, much less making it the default? |
Most of the discussion around this PR is on the thread for PR #33021, which is my preferred solution. tl;dr: Everybody would like to get rid of DEP0018, but there's disagreement about how to do that. Some Node TSC members think the default should be to throw an exception (and thereby crash, by default), and others think the default should be to just log a warning and delete the DEP0018 warning, saying it was a mistake to deprecate unhandled rejections. (One TC39 member in the thread argued that the default shouldn't even log a warning on unhandled rejections, though he accepted logging a warning as a compromise.) The option adopted here, to set an exit code while logging the warning, was raised as a compromise solution between the two main groups. It doesn't crash the process, which may satisfy those who feel that rejected promises are not exceptional, but it does indicate a problem via the exit code. TSC plans to survey node users about this in a few weeks, and then vote on a solution. |
...at some point, when the process finally exits. This could be hours or even weeks later. And that's if no other code sets Frankly, this "compromise solution" is basically useless, and I will repeat what I said on the other PR here:
Anyway thanks for making the PRs! |
Closing as decision was to move forward with |
This is a semver-major change that resolves DEP0018.
In addition to changing the default value for --unhandled-rejections,
this PR changes the exit code from 1 to 66. The warning message has
been updated to mention the new exit code, which I selected in order
to make this problem easier to search for on the web.
Users can prevent this behavior by setting a non-default value for the
--unhandled-rejections flag (throw, strict, warn, or none) or by setting
a hook for 'unhandledRejection'. This change has no effect on users who
have already set the flag or installed an 'unhandledRejection' hook; it
will only impact users who currently see a DEP0018 warning today.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes