javascript - 明显多余的 "unhandledRejection"事件被触发

Question

我们为 "unhandledRejection" 添加了一个事件处理程序在我们的 Node 应用程序中，此处理程序会终止进程(正如 Node 所说，很快将成为默认处理程序)。

然而，我们看到了一些看似多余(或至少为时过早)的事件。

我们正在使用 Q.allSettled (处理被拒绝的 promise )，我在调试器中看到 promise 数组有两个元素，第一个 rejected 和第二个 pending (它将被resolved )。在unhandledRejection中放置断点后处理程序和 then继 allSettled ，我得到unhandledRejection首先和之后立即 then (因此拒绝已被处理)。

unhandledRejection 的文档说(强调我的):

The 'unhandledRejection' event is emitted whenever a Promise is rejected and no error handler is attached to the promise within a turn of the event loop.

我的假设是，创建 Promise 数组的机制在第一个被拒绝的 Promise 和创建数组之间被阻塞，但我无法在玩具示例中重现这一点。

我能想到的最好的最小示例有点做作，但我认为它与我们的代码具有相同的根本原因。我在这里错过了什么吗？ Node 如何制作unhandledRejection如果可能的话，默认终止进程？

process.on("unhandledRejection", (reason, p) => {
    console.error(`### Got unhandled rejection: '${reason}'`);
});


function doesNotFireUnhandledRejection() {
    let rejected = Promise.reject('an error');
    return new Promise((resolve, reject) => {
        resolve(rejected);
    })
    .catch(err => console.log("Caught:", err));
}


function firesUnhandledRejection() {
    let rejected = Promise.reject('an error');
    return new Promise((resolve, reject) => {
        setTimeout(() => resolve(rejected), 0);
    })
    .catch(err => console.log("Caught:", err));
}

顺便说一句，setImmediate 也会发生同样的行为但不包括 process.nextTick (尽管我可以发誓上周 process.nextTick 确实导致事件触发...)。

Answer 1

这是在未处理的拒绝时终止进程的方式(预计是 future 版本中的默认 Node 行为):

process.on('unhandledRejection', err => {
  console.error(err);
  process.exit(1);
});

被拒绝的 promise 应该在同一个tick上与catch(...)或then(..., ...)链接，否则被认为是未处理的拒绝.

在极少数情况下，当保证稍后处理拒绝时，可以将 Promise 与虚拟 catch 链接起来，以抑制对未处理拒绝的检测:

function firesUnhandledRejection() {
    const rejectedPromise = Promise.reject('an error');
    rejectedPromise.catch(() => {});

    return new Promise((resolve) => {
        setTimeout(() => resolve(rejectedPromise), 0);
    })
    .catch(err => console.log("Caught:", err));
}