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

11–20 of 72 posts

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

#11

Post by oweiler »

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, bigger projects typically include multiple different, incompatible result types.

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

#12

Post by girvo »

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, doing embedded firmware) it feels like you’re fighting against the current, sadly.

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

#13

Post by qalmakka »

quickthrower2 wrote: post #7

This is sort of saying "exceptions were a mistake", right?

Exceptions are undoubtedly a mistake, because error handling is to important to untie errors completely from the code that generates them. That doesn't mean that stack unwinding doesn't have its uses.

For instance I find very convenient to use C++'s exceptions for truly exceptional cases - those in which I'd like the software to quit but I don't think aborting is a good solution (because maybe I want to properly clean up the application's state, etc). That's why Rust for instance uses C++ stack unwinding for `panic!`.

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

#16

Post by jwhiles »

slawr1805 wrote: post #6
musicq wrote: post #2

Spent sometime to complete the document of my rust Result like library `unwrapit` for JS/TS. Still think this might be a proper way to deal with errors in JS/TS

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

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

#17

Post by koenraad »

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,…

You are talking about a larger fundamental problem; code quality. This library can be a way to handle errors just as the try/catch block is. If agreed on within the team ofcourse.

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

#18

Post by eyelidlessness »

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 focus their error handling efforts in misleading ways.

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

#19

Post by Nezteb »

satvikpendem wrote: post #9

Just use a library that already contains this and more functional programming idioms, like fp-ts or its successor, Effect [0]. It is a little more complex to learn but much more robust that simply implementing your own Result and other types. [0] https://www.effect.website/

A great introduction video on Effect: https://www.youtube.com/watch?v=SloZE4i4Zfk

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

#20

Post by tgv »

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.
Post reply on HN