Would 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.
still a dependency
Unwrapit provides a way to handle errors in JS/TS
61–70 of 72 posts
Re: Unwrapit provides a way to handle errors in JS/TS
#62Earlier quoted context omitted.
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.
"recoiling at how much of a good idea it is" "recoiling" implies a negative response, ie revulsion or fear
Ahh, most likely meant to say recalling then.
Re: Unwrapit provides a way to handle errors in JS/TS
#63I'm not sure I agree with this approach, but I'd add instructions on how you would do unit testing when using this library.
Re: Unwrapit provides a way to handle errors in JS/TS
#64Why 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.
Because errors have different semantics. Some should kill your whole app and propagate up to the top layer, where a transaction that wraps the whole http request will be cancelled, or a error screen will be shown to the user. But other errors are part of business as usual — they should be handled explicitly, and type system should force you to do it and match the right exception type.
Personally though I would go with fp-ts.
Re: Unwrapit provides a way to handle errors in JS/TS
#65This 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 clea…
[flagged]
Re: Unwrapit provides a way to handle errors in JS/TS
#66My manager likes to ask "is it better or is it just different"
Well... It's certainly different.
Re: Unwrapit provides a way to handle errors in JS/TS
#67Earlier quoted context omitted.
That seems a lot more ergonomic. I can already see someone copy-pasting `wrap(myFunction)(args)` everywhere :-)
I think the most usual way in a project is to use this style. Wrap is a simple way to let you get Result type without refactoring your implementation. https://musicq.gitbook.io/unwrapit/recipe/return-result-with...
Then I'm tightly coupling all my code to this library. I would prefer to write javascript like normal and not import a library anytime I author a function.
Re: Unwrapit provides a way to handle errors in JS/TS
#68.catch
Re: Unwrapit provides a way to handle errors in JS/TS
#69Will throw this in here as it's been useful for errors if operating with try/catch
Re: Unwrapit provides a way to handle errors in JS/TS
#70For anyone who has NOT written in rust yet, there's nothing in the readme that explains what's intuitive or easy about the library. It doesn't even explain what to expect as the `status` getting logged, not go mention other possible values.
Thank you for the suggestion! I will add that.
Thank you!