前言

寫異步函數(shù)的時候，promise 和 async 兩種方案都非常常見，甚至同一個項目里，不同的開發(fā)人員都使用不同的習慣, 不過關于兩者的比較不是本文關注的重點，只總結為一句話：“async 是異步編程的終極解決方案”。

當使用 async 函數(shù)的時候，很多文章都說建議用 try catch 來捕獲異常, 可是實際上我看了很多項目的代碼，遵循的并不是嚴謹，很多都沒有用，甚至 catch 函數(shù)都沒寫，這是為什么呢？

我們先看下使用 try catch 情況下的代碼示例：

示例1 ：使用 try catch

執(zhí)行后會在 catch 里捕獲 請求異常，然后 getUserInfo 函數(shù)中斷執(zhí)行，這是符合邏輯的，對于有依賴關系的接口，中斷執(zhí)行可以避免程序崩潰，這里唯一的問題是 try catch 貌似占據(jù)了太多行數(shù)，如果每個接口都寫的話看起來略顯冗余。

示例2： 直接 catch

鑒于正常情況下，await 命令后面是一個 Promise 對象, 所以上面代碼可以很自然的想到優(yōu)化方案：

執(zhí)行后 catch 可以正常捕獲異常，但是程序沒有中斷，返回值 userInfo 為 undefined, 所以如果這樣寫的話，就需要對返回值進行非空校驗,  if (!userInfo) return 我覺得這樣有點反邏輯，異常時就應該中斷執(zhí)行才對；

示例3：在 catch  里 reject

可以繼續(xù)優(yōu)化，在 catch 里面加一行 return Promise.reject(e), 可以使 await 中斷執(zhí)行；

完整代碼：

一般我們在項目里都是用 axios 或者 fetch 之類發(fā)送請求，會對其進行一個封裝，也可以在里面進行 catch 操作，對錯誤信息先一步處理，至于是否需要 reject，就看你是否想要在 await 命令異常時候中斷了；不使用 reject 則不會中斷，但是需要每個接口拿到 response 后先 非空校驗， 使用 reject 則會在異常處中斷，并且會在控制臺暴露  uncaught (in promise)  報錯信息。

建議

不需要在 await 處異常時中斷，可以這樣寫，需要做非空校驗，控制臺不會有報錯信息

let userInfo = await getUserInfo().catch(e => console.warn(e))

if (!userInfo) return

需要在 await 處異常時中斷，并且在意控制臺報錯，可以這樣寫

需要在 await 處異常時中斷，但是不在意控制臺報錯，則可以這樣寫

總結

幾種寫法，初看可能覺得第三種 catch 這種寫法是最好的，但是細想下，從用戶體驗上來看，我覺得 try catch 是最好的，邏輯直觀、符合同步編程思維，控制臺不會暴露 uncaught (in promise) 報錯信息；

而鏈式調用的 catch (里面再 reject)，是傳統(tǒng) promise 的回調寫法，既然已經(jīng)用 async await 這種同步編程寫法了，再用 catch 鏈式寫法，感覺沒必要。

原文鏈接