In certain projects I can see why you would reach for functional style error handling, but for the vast majority of standard web apps/apis (what people are typically building in JS/TS) try/catch is far superior. Have the error bubble up to your endpoint, serve either a specific error message or a vague error message depending on error type, log accordingly. This is so simple, much quicker to develop and provides all the functionality you need. You can still use returned errors in the places that really call for it, but in my experience those instances are in the minority.
Unwrapit provides a way to handle errors in JS/TS
41–50 of 72 posts
Re: Unwrapit provides a way to handle errors in JS/TS
#42I'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.
That's the big if, but even if your team agress to use this, the greater JS ecosystem doesn't, so you end up being the odd one out.
"Law of least surprise" is a good thing to keep in mind when writing maintainable code.
Re: Unwrapit provides a way to handle errors in JS/TS
#43In certain projects I can see why you would reach for functional style error handling, but for the vast majority of standard web apps/apis (what people are typically building in JS/TS) try/catch is far superior. Have the error bubble up to your endpoint, serve either a specific error message or a vague error message depending on error type, log accordingly. This is so simple, much quicker to develop and provides all…
Ironically, I bet that a lot of React-driven apps use try/catch on a regular basis. Despite not doing a deep dive into the topic, I believe React's "asynchronous" (Suspense?) functional components actually throw Promises, and the runtime awaits them before re-rendering the component.
Re: Unwrapit provides a way to handle errors in JS/TS
#44Earlier quoted context omitted.
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.
Take the following function:
function arrmin(a: T[]): number {
let m = a[0].field;
for (let i = 1; i Re: Unwrapit provides a way to handle errors in JS/TS
#45I'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,…
One of the advantages of libraries such as these (in my opinion) is it gives you the ability to incorporate the errors thrown into the return type of functions, creating a broader contract than you would ordinarily achieve.
This is mainly in the context of TypeScript (think IntelliSense, etc.), also considering the fact that TypeScript doesn't support typed errors (neither does Flow, FWICS).
Then again, wrapping everything is a huge pain.
Re: Unwrapit provides a way to handle errors in JS/TS
#46Just 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/
Effect looks great. Strangely enough, I recall dreaming of it and recoiling at how much of a good idea it is -- can't wait to give it a proper go in a project.
Re: Unwrapit provides a way to handle errors in JS/TS
#47Why make it complicated? The language supports catching errors, use that. You may not like it but that's the thing you have. Of course you can wrap errors, return [response,error] or whatever in your implementation of api calls etc. but you don't need third-party libraries for that.
Agree with that. Exceptions suck, try-catch is an infamy, and errors not in the signatures or exploitable in any way by Typescript is a living nightmare. But what I hate even more is multiple ways to handle errors.
Re: Unwrapit provides a way to handle errors in JS/TS
#48Why make it complicated? The language supports catching errors, use that. You may not like it but that's the thing you have. Of course you can wrap errors, return [response,error] or whatever in your implementation of api calls etc. but you don't need third-party libraries for that.
Agree with that. Exceptions suck, try-catch is an infamy, and errors not in the signatures or exploitable in any way by Typescript is a living nightmare. But what I hate even more is multiple ways to handle errors.
You sound like, living in a car society is a nightmare because you can't dodge cars that run into you.
Hopefully there's an ideal world for you.
Re: Unwrapit provides a way to handle errors in JS/TS
#49Would be nice if this didn't have a dependency on rxjs just for a single use of Observable
Actually rxjs is a `peerDependency` which means it will assume the user will have it installed already.
Re: Unwrapit provides a way to handle errors in JS/TS
#50Will throw this in here as it's been useful for errors if operating with try/catch