寫了 promise 方法後，想到平常專案都很自然使用 Promise.all，突然好奇如果改成 Promise.allSettled 會發生什麼改變，畢竟後者感覺也是很實用的選項。

找到的一個案例是同時進行多個非同步函式，因為不同結構和邏輯，各函式內有自己的結果和錯誤處理。Promise.all 的地方很簡單，大概像這樣：

const requests = ['fetchLogin', 'fetchUser', 'fetchArticles']

Promise.all(requests.map(request => dispatch(request)));

像這樣使用 Promise.all 時，當其中一個任務出錯可能有幾種狀況：

1. 如果函式內有 catch 錯誤處理，一切無事。(這部分有完整結束、錯誤不會傳出去、不會影響別的任務。)
2. 如果函式內沒有錯誤處理，或是再拋出錯誤，這個任務連帶整個 Promise.all 會變 rejected，其他成功的任務也得不到結果。(當然這種情況代表外層要加上相對應的錯誤處理。)

如果換成 Promise.allSettled，跟上述同樣的狀況時：

1. 一切無事，這個任務狀態會是 fulfilled。
2. 這個任務的狀態為 rejected，其他成功的任務依然會得到結果。

可以說，在函式內有各自錯誤處理時，基本上都會是情況 1.，所以用 Promise.all 和 Promise.allSettled 的差異不大，都可以做到任一個壞掉也不會影響其他。

可是如果各函式內會再拋出錯誤，代表 promise 會有 rejected 狀態，也就代表兩個方法會有不同結果。如果這種時候外層做的是總處理 (例如先顯示錯誤頁面，再來細查哪個任務裡有不可修復的錯誤)，感覺用 all 即可；如果這時候還有更精細的錯誤分析，可以善用 allSettled 的錯誤訊息，然後同時頁面上也能保持其他成功的內容。

雖然這只是個案，但我想除了一般對用途和成功結果的考量，選擇 promise 方法時也可以考慮進錯誤處理需求。