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

31–40 of 72 posts

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

#31

Post by chmod775 »

tentacleuno wrote: post #30
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.)

There's a fair chance modern JS engine's Promise implementations are going to beat a custom wrapper function that is also wrapping everything, contains a try/catch statement, multiple typeofs, and creates an instance of a class for every result.

Not that it matters - if you're going down this route either way, performance is not your priority. If you really care about performance, don't use either if you don't have to.

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

#32

Post by tentacleuno »

meowtimemania wrote: post #29

I'd prefer an api like this: const [result, error] = attempt(() => someFunc()); This way you don't have to wrap all your functions.

That seems a lot more ergonomic.

I can already see someone copy-pasting `wrap(myFunction)(args)` everywhere :-)

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

#33

Post by tentacleuno »

chmod775 wrote: post #31
tentacleuno wrote: post #30

Earlier quoted context omitted.

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.)

There's a fair chance modern JS engine's Promise implementations are going to beat a custom wrapper function that is also wrapping everything, contains a try/catch statement, multiple typeofs, and creates an instance of a class for every result. Not that it matters - if you're going down this route either way, performance is not your priority. If you really care about performance, don't use either if you don't have t…

No, the whole point of Promise implementations is not to beat tasks which run in the current event loop tick. That's why you have separate (microtask, macrotask etc.) queues in the first place.

Unnecessarily using Promises introduces further work for the VM, plus it may cause issues with race conditions, wrong variable values (which aren't easy to debug), etc. if you don't hold a magnifying glass to your code.

To be clear, I'm not benchmarking OP's library -- just providing an important note on why you shouldn't use Promise as a general monad. There are libraries for that: maybe not this one, maybe nothing at all. Do whatever works for you :-)

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

#34

Post by the_gipsy »

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…

That would make everything async which is not what you want.

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

#35

Post by redact207 »

trungdq88 wrote: post #23

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".

I think their reasoning is that it's type safe so the compiler complains that you didn't handle something that returns an error.

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

#37

Post by randomdev3 »

Why 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.

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

#38

Post by chmod775 »

tentacleuno wrote: post #33
chmod775 wrote: post #31

Earlier quoted context omitted.

There's a fair chance modern JS engine's Promise implementations are going to beat a custom wrapper function that is also wrapping everything, contains a try/catch statement, multiple typeofs, and creates an instance of a class for every result. Not that it matters - if you're going down this route either way, performance is not your priority. If you really care about performance, don't use either if you don't have t…

No, the whole point of Promise implementations is not to beat tasks which run in the current event loop tick. That's why you have separate (microtask, macrotask etc.) queues in the first place. Unnecessarily using Promises introduces further work for the VM, plus it may cause issues with race conditions, wrong variable values (which aren't easy to debug), etc. if you don't hold a magnifying glass to your code. To be…

> No, the whole point of Promise implementations is not to beat tasks which run in the current event loop tick. That's why you have separate (microtask, macrotask etc.) queues in the first place.

We're clearly talking about actual CPU time spent here when comparing code using those approaches. We're not interested in what runs first in some software mixing synchronous and asynchronous code. This is completely irrelevant.

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

#40

Post by tentacleuno »

chmod775 wrote: post #38
tentacleuno wrote: post #33

Earlier quoted context omitted.

No, the whole point of Promise implementations is not to beat tasks which run in the current event loop tick. That's why you have separate (microtask, macrotask etc.) queues in the first place. Unnecessarily using Promises introduces further work for the VM, plus it may cause issues with race conditions, wrong variable values (which aren't easy to debug), etc. if you don't hold a magnifying glass to your code. To be…

> No, the whole point of Promise implementations is not to beat tasks which run in the current event loop tick. That's why you have separate (microtask, macrotask etc.) queues in the first place. We're clearly talking about actual CPU time spent here when comparing code using those approaches. We're not interested in what runs first in some software mixing synchronous and asynchronous code. This is completely irrelev…

> We're clearly talking about actual CPU time spent here when comparing code using those approaches. This is completely irrelevant.

Perhaps I missed a part of the conversation? I began by highlighting the issues with your approach regarding the event loop, and you started talking about the implementation of this library in particular, seemingly as a counter-argument?

To be clear, I'm not disagreeing that wrapping things is slower than not wrapping them. That's quite obviously true. I'm just pointing out bad advice in your parent comment.

Post reply on HN