起初我在整個打字稿/節點應用程式中使用了 throw 和 catch 之后，我偶然發現了 neverthrow（https://www.npmjs.com/package/neverthrow）。
我寫了我的第一個更大的應用程式和打字稿，才意識到缺少將函式標記為 throwing 的能力實際上是一個多么大的問題。
neverthrow 或其他基于任何一種的解決方案似乎都很好。對于我的非異步函式，我已經將所有內容更改為 neverthrow。
我真的不明白這一點，為什么我應該費心去包裝我所有的異步函式來回傳 ResultAsync 。任何異步函式都被標記為可能在本質上拋出錯誤（因為它們回傳一個 Promise），還是我錯了？我是否遺漏了任何一點，我確實應該將所有異步函式更改為使用 ResultAsync？
uj5u.com熱心網友回復：
使用類似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.
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/340949.html