process: change default --unhandled-rejections=strict

[dfabulich]

This is a semver-major change that resolves DEP0018.

This commit also adds a new --unhandled-rejections=warn-unhandled
option, which mimics the previous default behavior. When using
warn-unhandled, a warning is emitted only if the unhandledRejection
hook fails to handle the event. The behavior of warn, unchanged in
this commit, is to omit a warning no matter whether the
unhandledRejection hook is set.

Fixes: #20392
Refs: https://nodejs.org/dist/latest/docs/api/deprecations.html#deprecations_dep0018_unhandled_promise_rejections

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[dfabulich]

The PR build failed in the "Build from tarball" step, but I see no logs or error messages there, and it passed the "build-windows" "test-linux" and "test-macOS" steps.

Is there a way for me to reproduce this error? Or perhaps the failure is ephemeral? Could I re-run the build somehow?

[devsnek]

We still don't have consensus in #20392

[mmarchini]

If we decide to land this, we definitely want it on a odd version, so we can revert it if needed before an LTS release, so the timing right now is good.

The PR build failed in the "Build from tarball" step, but I see no logs or error messages there, and it passed the "build-windows" "test-linux" and "test-macOS" steps.

It looks like something failed on the action, not sure why. Don't worry though, the other tests passed, and either way GitHub Actions is not our main CI, I'll start a Jenkins job for you.

This will need a CITGM run as well.

We still don't have consensus in #20392

@devsnek are you objecting to the PR direction or to landing this before further discussion? I remember you suggested going in the other direction in #25747.

@dfabulich just want to give you a heads up that folks are very passionate about this topic, and it'll probably take some time for this PR to land or be rejected (if consensus is reached at all).

[devsnek]

@mmarchini I'm against it, and I also don't think we came to a consensus in the linked issue.

[addaleax]

A smaller first step might be to not change behaviour to throwing an exception, but adding process.exitCode = 1; in the case of an unhandled rejection. That fulfills the wording of DEP0018 and is probably more likely to reach consensus?

[mmarchini]

TSC will be voting on the intended default behavior for unhandled rejections on v15, where we also intend to remove the deprecation warning. We want to listen to Node.js users experiences with unhandled promises and what you think should be the default before voting, so we prepared a survey: https://www.surveymonkey.com/r/FTJM7YD

We also wrote an accompanying blog post for extra context: https://medium.com/@nodejs/node-js-promise-reject-use-case-survey-98e3328340c9

The survey will run for at least two weeks, at which point we'll evaluate if the number of replies is enough for us to move forward, otherwise we might extend it for a week or two. Please fill out the survey as it will help us decide the future of unhandled promise rejections on Node.js!