Lastor
@Lastor
說
Tue, Dec 27, 2022 7:25 AM
coding memo
Say goodbye Trycatch Hell
Lastor
@Lastor
Tue, Dec 27, 2022 10:16 AM
今天在等其他人的東西處理完，就研究了一下 try catch 有啥優化途徑
Lastor
@Lastor
Tue, Dec 27, 2022 10:17 AM
感覺這水有點深啊...... 雖然確實是可以另外封包成一個 function 處理，但 onError 的靈活度會下降，而且會有一種很強烈的過度包裝的感覺
Lastor
@Lastor
Tue, Dec 27, 2022 10:18 AM
嘗試了 3 種類似思路，但封裝方式不太一樣的做法，似乎上面貼的那篇 Go 風格的，是寫起來最順手的
Lastor
@Lastor
Tue, Dec 27, 2022 10:18 AM
但不適合我們家的專案......
Lastor
@Lastor
Tue, Dec 27, 2022 10:19 AM
我們家這邊，前人留下的機制，所有 request 都會發到 Server 端代理轉發
Lastor
@Lastor
Tue, Dec 27, 2022 10:20 AM
而這層轉發回來，前端接到的必定是 200
Lastor
@Lastor
Tue, Dec 27, 2022 10:21 AM
所以這樣包裝其實沒有意義，那個 err 永遠都是空的
const [res, err] = await tryTo(...some promise)
Lastor
@Lastor
Tue, Dec 27, 2022 10:22 AM
錯誤訊息會包在 response 裡面發過來
Lastor
@Lastor
Tue, Dec 27, 2022 10:22 AM
也就是說，因為永遠都會是 200，所以其實根本不需要寫 try catch 啊
Lastor
@Lastor
Tue, Dec 27, 2022 10:23 AM
害我在那邊 try 了老半天
Lastor
@Lastor
Tue, Dec 27, 2022 10:24 AM
這邊後端有規格，如果 Error 的話，會在 response body 裡面塞一個布林的 key 表示成功語法
Lastor
@Lastor
Tue, Dec 27, 2022 10:25 AM
只要去判斷那個 key 就好，不需要擔心 HTTP status 是非 200 的情況
Lastor
@Lastor
Tue, Dec 27, 2022 10:26 AM
===========
但如果是平常沒有走特殊機制，單純用 axios 去接的話，那個 Go 風格的包裝方式就可以 work 了
載入新的回覆