typescript - Vad är poängen med neverthrow för asynkrona funktioner?
Efter att jag först hade använt throw och catch i hela min typescript/node-applikation snubblade jag över neverthrow(https://www.npmjs.com/package/neverthrow).
Det tog mig att skriva min första, större applikation och TypeScript, för att inse hur stort problem den saknade möjligheten att markera en funktion som kastande faktiskt är.
neverthrow eller andra baserade lösningar verkar bara bra. För mina icke-Async funktioner har jag redan ändrat allt till neverthrow.
Jag ser egentligen inte poängen med varför jag skulle besvära mig med att göra om alla mina asynkrona funktioner för att returnera ResultAsync. Vilken som helst asynkron funktion är ju av naturen markerad som att den eventuellt kan kasta ett fel (eftersom de returnerar ett Promise), eller har jag fel? Finns det någon poäng jag missar och borde jag faktiskt ändra alla asynkrona funktioner för att använda ResultAsync?
Svar #1
Det finns få fördelar med att använda något som ResultAsync<T, E>-typen istället för en Promise<T>.
Som kan ses från typen själv, har det tidigare alternativet en E-generisk parameter som indikerar vilka typer av fel resultatet kan innehålla. Detta är väldigt fördelaktigt, eftersom du kan hantera varje feltyp oberoende istället för att fånga en generisk felinstans. Ta till exempel HTMLImageElement.decode; det returnerar ett löfte som kan kasta EncodingError, men du skulle inte veta det utan att kontrollera dokumentationen.
En annan fördel kommer från att man tvingas hantera det potentiella felresultatet. Javascript-fel är okontrollerade, vilket betyder att det inte finns någon kompilator eller tolk som ser till att du alltid omger await promise med en try-catch. Å andra sidan, när du await result, måste du kontrollera om det gav ett resultat (result.isOk() === true) eller kastade ett fel (result.isErr() === true). Detta innebär att varje gång du vill avkoda (få T från Result<T, _>) ett resultat måste du hantera de potentiella fellägena. I teorin resulterar detta i mer robust och felfri kod.
Resultat kommer dock inte utan nackdelar. Javascript-ekosystemet har antagit Promises som standardmetod för att returnera saker asynkront, så ResultAsync kanske inte fungerar överallt där Promise skulle göra det. Dessutom gör det att man måste hantera potentiella felresultat varje gång man vill packa upp ett resultat att koden blir mer omständig.
Om du mest arbetar med asynkron kod skriven inom samma projekt och tror att du skulle kunna dra nytta av mer felfri kod, kan det vara vettigt att använda ResultAsync överallt där du skulle använda Promise.