Używanie do oczekiwania… lub z synchronicznymi iteracjami

MDN mówi, że for await...of ma dwa przypadki użycia:

for await...ofInstrukcja tworzy pętlę iteracji nad asynchroniczny iterable obiektów, jak również na iterables synchronizacji ...

Wcześniej zdawałem sobie sprawę z pierwszego: asynchroniczne iterowanie przy użyciu Symbol.asyncIterator. Ale interesuje mnie teraz to drugie: iteracje synchroniczne.

Poniższy kod iteruje iterację synchroniczną - tablicę obietnic. Wydaje się, że blokuje postęp w wypełnianiu każdej obietnicy.

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)

Zachowanie wydaje się podobne do oczekiwania na każdą obietnicę po kolei, zgodnie z logiką przedstawioną poniżej. Czy to twierdzenie jest prawidłowe?

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)

Pytam, ponieważ ten wzór kodu ma niejawny odrzucenia wire-up pułapki że Promise.alli Promise.allSettledunikania, a wydaje mi się dziwne, że ten wzór będzie wyraźnie wspierane przez język.

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)

Tak, to dziwne i nie powinieneś tego robić. Nie iteruj tablic obietnic, prowadzi to dokładnie do wspomnianego problemu nieobsługiwanych odrzuceń .

Dlaczego to jest obsługiwane w języku? Kontynuacja niedbałej semantyki.

Dokładne uzasadnienie można znaleźć w tym komentarzu do kwestii omawiającej tę część wniosku :

Myślę, że powinniśmy do tego wrócić, Symbol.iteratorponieważ nasza obecna semantyka Obietnicy polega na umożliwieniu synchronizacji rzeczy jako asynchronicznych. Możesz to nazwać „niechlujstwem”. Wynika to z powyższej logiki @ wód podziemnych , ale chcę bardziej szczegółowo opisać podobieństwa.

Chodzi .thentu o semantykę „łańcuchów” . Możesz zwrócić Obietnicę od .thenlub wartość skalarną; to wszystko jest takie samo. Dzwonisz, Promise.resolveaby nie zawijać czegoś w obietnicy, ale rzucić coś na obietnicę - uzyskać wartość asynchroniczną, gdy masz coś takiego lub innego.

Semantyka asynci awaitdotyczy również niedbałości. Możesz spoliczkować awaitdowolne wyrażenie inne niż Promise w funkcji asynchronicznej i wszystko działa dobrze, dokładnie w ten sam sposób, z wyjątkiem tego, że poddajesz kontrolę kolejce zadań. Podobnie możesz „obronnie” async ominąć wszystko, co chcesz, pod warunkiem, że uzyskasz awaitwynik. Jeśli masz funkcję, która zwraca Obietnicę - cokolwiek! możesz uczynić tę asyncfunkcję i, z perspektywy użytkownika, nic się nie zmieni (nawet jeśli z technicznego punktu widzenia uzyskasz inny obiekt Promise).

Asynchroniczne iteratory i generatory powinny działać w ten sam sposób. Tak jak możesz oczekiwać wartości, która przypadkowo nie była obietnicą, rozsądny użytkownik spodziewałby się, że będzie w stanie yield*zsynchronizować iterator w generatorze asynchronicznym. for awaitPętle powinny podobnie „po prostu działać”, jeśli użytkownik w ten sposób obronnie oznaczy pętlę, sądząc, że może uzyskać iterator asynchroniczny.

Myślę, że złamanie wszystkich tych podobieństw byłoby wielką rzeczą. Sprawiłoby to, że iteratory asynchroniczne byłyby mniej ergonomiczne. Omówmy to następnym razem, gdy generatory / iteratory asynchroniczne pojawią się w porządku obrad na TC39.

sadObietnica nie będąc awaited kiedy to się nie powiedzie - że potrzebuje kod do końca czeka na happyzanim zacznie czekać na sad. sadObietnica zawodzi przed happyustąpienia objawów. ( Promise.alljest narzędziem, które lepiej nadaje się do tego przypadku użycia)