使用 for await...of 与同步迭代

Question

MDN says for await...of 有两个用例：

for await...of 语句创建了一个循环遍历 async 可迭代对象以及同步可迭代对象，...

我之前知道前者：使用Symbol.asyncIterator 的异步迭代。但我现在对后者感兴趣：同步迭代。

以下代码迭代同步可迭代对象 - 一组承诺。它似乎阻碍了每个承诺的兑现。

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('happy'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('sad')))
        const promises = [happy, sad]
        for await(const item of promises) {
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

根据下面显示的逻辑，该行为似乎类似于依次等待每个承诺。这个说法正确吗？

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('happy'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('sad')))
        const promises = [happy, sad]
        for(let p of promises) {
            const item = await p
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

我之所以这么问，是因为这种代码模式有一个隐含的拒绝连接陷阱，Promise.all 和 Promise.allSettled 避免了这种错误，而且这种语言会明确支持这种模式对我来说似乎很奇怪。

window.addEventListener('unhandledrejection', () => {
  console.log('unhandled rejection; `sad` was not being awaited at the time it rejected')
})

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('success'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('failure')))
        const promises = [happy, sad]
        for(let p of promises) {
            const item = await p
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "unhandled rejection; `sad` was not being awaited at the time it rejected" (after about zero seconds), and then "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

Answer 1

是的，这很奇怪，你不应该这样做。不要迭代承诺数组，它会引导exactly to the unhandled-rejections problem you mentioned。 （另见this more specific explanation。）

那么为什么该语言支持这一点？继续使用草率的 Promise 语义。

你可以在this comment of the issue discussing this part of the proposal找到确切的推理：

我认为我们应该回到Symbol.iterator，因为我们目前的 Promise 语义都是关于允许将同步的东西用作 异步的东西。你可以称之为“草率”。它跟随 @groundwater's logic above, 但我只想更详细地说明相似之处。

.then 的“链接”语义都是关于这个的。你可以返回一个 来自.then 的承诺或标量值；这都一样。你打电话 Promise.resolve 不是在 Promise 中包装一些东西，而是投射 承诺的东西——当你有的时候得到一个异步值 某事或其他。

async 和 await 的语义也都是关于马虎的。 您可以在异步函数中的任何非 Promise 表达式上拍 await 一切正常，完全一样，除了你屈服 控制到作业队列。同样，您可以“防守”输入async 随心所欲，只要你await结果。如果你有 一个返回 Promise 的函数——无论如何！你可以把它变成 async 函数，并且从用户的角度来看，没有任何变化（甚至 如果从技术上讲，你得到一个不同的 Promise 对象）。

异步迭代器和生成器应该以相同的方式工作。就像你一样 可以等待一个意外地不是 Promise 的值，一个合理的值 用户希望能够yield* async 中的同步迭代器 发电机。 for await 循环应该同样“正常工作”，如果用户 以这种方式防御性地标记一个循环，认为他们可能是 获取异步迭代器。

我认为打破所有这些相似之处将是一件大事。它 会使异步迭代器更不符合人体工程学。让我们接下来讨论这个 时间异步生成器/迭代器出现在 TC39 的议程中。

Answer 2

sad 承诺不是当它失败时被awaited - 该代码需要在开始等待happy 之前完成等待sad。 sad 承诺在 happy 解决之前失败。 （Promise.all 是更适合此用例的工具）