Hi everyone! It is possible that it is here for the post title, and I daresay you have had problems handling errors with async/await. In this post ...
For further actions, you may consider blocking this person and/or reporting abuse
This is over-engineered to me
Actually, this error tuple-pattern is very common in Go.
In terms of error handling, my favorite is rust because it has less overhead. But it's uglier and a little bit more complicated.
Yes, I am a gopher, but do you think over 50% JavaScript developer using Go?
No! Of course not lol.
My point was — If a whole modern language, which is known as an easy-to-read language, uses a pattern like that as standard good practice maybe the pattern is not that over-engineered
It seems like this at first glance, but it will be useful when the use of
trycatch
becomes repetitive, and these functions allow you to always reuse them.It's a great solution, but it can be made even simpler. You will need another if statement to handle errors in your example. Why not just check if the promise is an error instance.
const res = await (promise).catch((e) => e).
If(res instanceof Error) {
// Handle err
}
Mm... I've never thought about it, I like your solution. Thanks!
this exactly how I catch errors, and I was wondering whole time reading article "why is there a problem?" However I like wrapper util :)
You need to catch exceptions on the top level of the function and try not to use the try catch scope until you need to re throw something specific.
With the following approach we are hiding
unhandled
rejections by providing status code 500 (Database errors for example) and only the correct thrown exceptions will be shown as a result of the requester.Done years ago of.js.org
Another exemple : await-to-js that returns the error first to enforce it to be handled :
Was about to point out it all seemed a bit like re-inventing the wheel, considering modules like this already exist.
I personally use and like await-to-js for many use cases.
I like, but is not necessary why is Typescript being used (as long as the developer uses static typing)
There's a simple solution. Whatever you
await
should usually return a promise and thus can be directly caught:Completely pointless refactor exercise IMHO, as now instead of try/catch-ing you need to check each time if a function returned an error or not.
When an exception is thrown it will jump out of all blocks, so there's no need to catch it at the same level. You can set just a single try/catch block on the parent (or even higher) scope to catch all of them.
I usually do
Or I'd just throw an error inside the getUserData function
Thank you for your contribution, my friend.
Personally, I do not like to handle errors that way, I consider them incorrect, I leave you the link so you can take a look about making these exceptions: developer.mozilla.org/docs/Web/Jav...
Now we handle it.
Sure, I actually like the golang pattern because is easy to read.
Also I got a different approach by asking about this.
if (error)
in the code, and it will be even worse.This is too complicated, I usually do this
Because you have to know, promsie comes with try/catch
Starts to look a lot like GoLang, nice
Although I find your handler example to be a bit over complicated.
This is going in the direction of Maybe or Either monads.
This matter has been discussed many times. It's better to return the error as the first element to coerce consumers into always handling errors, otherwise it's easy to forget.
In this case, it will be hard to forget, since Typescript is used, so you will know that it is the answer or a null value. Thank you for your comments.
github.com/supermacro/neverthrow is something to look at, not only avoids the trycatch hell but it also provides a way to easily compose computations!
I've been going through the package and it looks interesting. Thanks for your contribution.
Love it, in golang people discuss if they want exceptions or not, in Javascript you have them and can decide to just not to.
Goodbye trycatch hell, hello Promise-async-await hell...
you lost me at interfaces, not that i didn't understand, but just lost me.
github.com/supermacro/neverthrow
Try this!
Not sure about golang, but you don't need this many try/catch in JS. Just handle an error only where you need to handle it. Otherwise let it go to a concerned parent.
This is very similar a post on f# blog some years ago ... fsharpforfunandprofit.com/rop/