起初我在整個打字稿/節點應用程序中使用了 throw 和 catch 之後，我偶然發現了 neverthrow（https://www.npmjs.com/package/neverthrow）。
我寫了我的第一個更大的應用程序和打字稿，才意識到缺少將函數標記為 throwing 的能力實際上是一個多麼大的問題。
neverthrow 或其他基於任何一種的解決方案似乎都很好。對於我的非異步函數，我已經將所有內容更改為 neverthrow。
我真的不明白這一點，為什麼我應該費心去包裝我所有的異步函數來返回 ResultAsync 。任何異步函數都被標記為可能在本質上拋出錯誤（因為它們返回一個 Promise），還是我錯了？我是否遺漏了任何一點，我確實應該將所有異步函數更改為使用 ResultAsync？
使用類似ResultAsync<T, E>類型而不是Promise<T>.
從類型本身可以看出，前一個選項有一個E泛型參數，指示結果可能包含的錯誤類型。這非常有益，因為您可以獨立處理每種錯誤類型，而不是捕獲通用錯誤實例。以HTMLImageElement.decode 為例；它返回一個可能會拋出的承諾EncodingError，但如果不檢查文檔，你就不會知道。
另一個好處來自被迫處理潛在的錯誤結果。Javascript 錯誤是未經檢查的，這意味著沒有編譯器或解釋器來確保您始終包含await promise在 try-catch 中。另一方面，當您 時await result，您必須檢查它是否產生了結果 ( result.isOk() === true) 或拋出了錯誤 ( result.isErr() === true)。這意味著每次您想要解包（T從Result<T, _>）結果時，您都必須處理潛在的錯誤情況。從理論上講，這會產生更健壯和故障安全的代碼。
然而，結果並非沒有缺點。Javascript 生態系統採用 Promise 作為異步返回事物的標準方式，因此ResultAsync可能無法在任何地方工作Promise。此外，每次要解包結果時都必須處理潛在的錯誤結果，這會使代碼變得更加冗長。
如果您主要處理在同一個項目中編寫的異步代碼並認為您可以從更多的故障安全代碼中受益，那麼ResultAsync在您使用Promise.
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句