Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unwrapit provides a way to handle errors in JS/TS

musicq.gitbook.io

Post reply on HN
Print view View original

21–30 of 72 posts

Re: Unwrapit provides a way to handle errors in JS/TS

#21

Post by jondwillis »

eyelidlessness wrote: post #18
jondwillis wrote: post #15

Is there a reason that typescript doesn’t/can’t add throwing function annotation syntax?

From memory: even if the arguments in favor were thoroughly convincing, it’s basically an insurmountable task to produce the types to cover even common runtimes, let alone the vast ecosystem of libraries (often themselves with community-maintained types). The failure mode for poor coverage of error types is worse than the failure mode of untyped errors, for instance because it would tend to influence where developers…

Maybe I am misreading you but for example, in Swift, marking a function as “throws” makes it a compiler error to not handle the error, and makes it an error to not throw an error or return in the function. In Typescript, the error in a catch handler is of type unknown. I don’t see how it could be any worse than basically untyped errors AND unpredictable runtime errors without reading the docs or implementation. At least you would get some compiler help.

Re: Unwrapit provides a way to handle errors in JS/TS

#22

Post by jondwillis »

tgv wrote: post #20
jondwillis wrote: post #15

Is there a reason that typescript doesn’t/can’t add throwing function annotation syntax?

I would guess it is because just about every function can throw, and TS can't detect it with certainty, even for functions which are 100% TS. It also doesn't improve transcription or performance.

Why can’t provenance of throws be traced with certainty? It is possible to trace the return type of functions.

Even if it were an opt-in/progressive adoption keyword like “throws” that enforced some compiler guardrails, I think that could be a huge win for reducing unexpected runtime exceptions.

Re: Unwrapit provides a way to handle errors in JS/TS

#23

Post by trungdq88 »

Maybe I'm old, but I can't see any reasons why this is better after looking at the before/after example. This is adding unnecessary complexity with very little benefit (if at all).

If anything, the "try...catch" example actually look clearer and better than "!user.ok".

Re: Unwrapit provides a way to handle errors in JS/TS

#25

Post by chmod775 »

Promises already are a wrapper that can contain an error or a value, and using 'await' is basically unwrapping it.

This library adds very little value and is just another layer of abstraction which removes the syntactic sugar that was added with the previous layer and tries to re-implement stuff we already have (like responding to uncaught errors).

Just use base promises and .then/.catch etc if you want to deal with values/errors this way. Don't introduce another dependency that does almost nothing, and which others reading your code will have to familiarize themselves with.

I get that this makes doing some things slightly more ergonomic and less verbose, but at the end of the day it saves you seconds while costing others who have to look up documentation/code of yet another library much more time. Not to mention yet another dependency with sub-dependencies you have to manage. It wants specifically rxjs ^7.8.1 despite only using stable parts of that API.

I probably just spent more time evaluating this thing than it ever would have saved me.

Re: Unwrapit provides a way to handle errors in JS/TS

#26

Post by ghosty141 »

girvo wrote: post #12
oweiler wrote: post #11

I've come to the conclusion that such a library offers little benefit in languages which embrace exceptions. You have to basically wrap everything , making the code hard to read, and without proper ADTs and pattern matching it's easy to forget handling all cases. There's also no way to prevent ppl from falling back to exceptions, so now you have a mess of exception and result handling. And bc there is no blessed way,…

Indeed. A fun example of this is Nim: “results” is quite a nice library, but Nim’s stdlib and by extension most of its third party libraries are built around exceptions (or std/options). And Nim uses effect tracking, you can encode the exceptions raised into the type signature, so in some ways it’s perfectly poised for something like “results” or unwrapit Yet when you try to go down that path (like we did at work, do…

I personally like the saying „when in rome, do as the romans do“. While you CAN retrofit almost anything to a lang, it tends to be a constant fighting against the current which is rarely worth it.

A good example is when working with Qt, trying to avoid QString and QObject as much as possible is a fools errand, its slower and ultimately ends up with ugly code.

Re: Unwrapit provides a way to handle errors in JS/TS

#27

Post by grose »

jwhiles wrote: post #16
slawr1805 wrote: post #6

Earlier quoted context omitted.

This is awesome! I dig this when using Rust and am pumped to try and sneak this in at work where we have a large TS codebase.

This is a nice project, but it kind of feels like the result of someone who's just learnt about Rust/Haskell and wants to port what they know to JavaScript. There's a lot of more established and battle tested libraries with the same functionality - I've recently been using Purify and finding it to be absolutely fine :) their version of the same feature is here: https://gigobyte.github.io/purify/adts/Maybe

Whoa, these docs are really nice. Love how it includes the functional Haskellish signature, TS signature, and useful examples for each. Props to the authors.

Re: Unwrapit provides a way to handle errors in JS/TS

#28

Post by sublinear »

ghosty141 wrote: post #26
girvo wrote: post #12

Earlier quoted context omitted.

Indeed. A fun example of this is Nim: “results” is quite a nice library, but Nim’s stdlib and by extension most of its third party libraries are built around exceptions (or std/options). And Nim uses effect tracking, you can encode the exceptions raised into the type signature, so in some ways it’s perfectly poised for something like “results” or unwrapit Yet when you try to go down that path (like we did at work, do…

I personally like the saying „when in rome, do as the romans do“. While you CAN retrofit almost anything to a lang, it tends to be a constant fighting against the current which is rarely worth it. A good example is when working with Qt, trying to avoid QString and QObject as much as possible is a fools errand, its slower and ultimately ends up with ugly code.

Try VTL

Re: Unwrapit provides a way to handle errors in JS/TS

#30

Post by tentacleuno »

chmod775 wrote: post #25

Promises already are a wrapper that can contain an error or a value, and using 'await' is basically unwrapping it. This library adds very little value and is just another layer of abstraction which removes the syntactic sugar that was added with the previous layer and tries to re-implement stuff we already have (like responding to uncaught errors). Just use base promises and .then/.catch etc if you want to deal with…

Promises are inherently going to be a lot slower than synchronous code (not to mention timing implications, re: the event loop, microtask queue, etc.). As such, wrapping everything in Promises is not a good idea -- reserve it for actually asynchronous operations.

(All of that's not even to mention the confusion around what operations in the code actually perform asynchronous actions.)

Post reply on HN