5 Async + Await Error Handling Strategies

[@zombiefacesupreme]

You know he's a tech dad when he not only has a box full of cables, but they're all properly bundled and organized.

[@WesBos]

haha that was a recent project! Used to be such a mess

[@whitefluffycloud]

Great summary! I've always struggled with error handling. How to set things up etc. This video was super helpful. Working a lot with React, the Go way makes a lot of sense.

[@Dunktastic17]

Nice to see you posting so much on KZbin lately! Always quality content!

[@WesBos]

I appreciate that!

[@Ouchie]

I was already using the Go way, but it is awesome to see that you can even expand it further.

[@ahmad-murery]

Returning object is better for someone likes me who can't remember what he did a few minutes ago 😁 Nice little girl 😍, I'm happy you didn't cut the video. Thanks Wes!

[@MB-zj3er]

I found this extremely helpful. Thank you for taking the time to make the video.

[@WesBos]

you're welcome!

[@newstory8568]

Always at the top 👌 Awesome video 👍

[@ГерриПитт]

Nice video. What is the extension you are using to log output right in editor? //?

[@nicolasparada]

The "Go" way is superior, but looks off to use it in javascript. If you use it in a team, other people might find it weird 😅 But is nice since you can clearly handle each error separately, and you avoid nesting code. You can repeat "if error return" and clearly see the happy path of the program.

[@brianmccoy9270]

Great video. How do you highlight your single line comments with the yellow background?

[@WesBos]

It’s a plugin called better comments. You write regex rules and the apply new styles. I have them for “method, exercise, solution, problem…”

[@moonstar_connor]

Great recap! I really like the Go way, but use the Rust way a lot because I use Supabase which does the same thing in its APIs (returning data, error, etc. for async operations)

[@WesBos]

Same thing with a lot of GraphQL libs - the Rust way seems more popular

[@apharos]

great video! Was exactly what I was looking for

[@David-gj6dc]

In Typescript, I prefer the go way using discriminated unions so you have to check either the data or error for a value

[@honza139706]

What editor/plugin does you use for whisperring and showing the data??

[@JanHonzaPozivil]

Re Method 4.0: What is the problem of using `null` in the returned tuple? Wes says that someone got mad at him over that on Twitter, but I'm struggling to see the reason why.

[@r-i-ch]

Great stuff! Question - You don't touch on try/catch/FINALLY blocks. What kind of data would a `finally` call have access to? Would it fit some of your error-handling use cases?

[@WesBos]

I did show it as one of the examples, but not the finally. That’s kinda like the allSettled, but it’s annoying because each try/catch/finally is scoped to its block, so you have to declare variables outside it. Has its use cases, especially when returning from a function, but not my go to

[@elmoutaouakkilmohammed1432]

Fantastic video! Thank you

[@Lambdaphile]

I think I like the third (go) variant the most. 4 and 4.1 is ok too, but only if the error is returned as the first element, like in the third variant. Also, can't you type the returned tuple with TypeScript?

[@WesBos]

Yep - I think I said that in the video!

[@mystic_monk55]

what is this extension which is showing the return value preview?

[@WesBos]

Quokka

[@DJAdams]

Came here just to say that your thumbnail game is strong with this video

[@WesBos]

hahaha thanks

[@bok7660]

Thanks a lot for these "cheeses". Btw, can I ask how can I achieve the font style / theme you used on your vs code editor?

[@WesBos]

Cobalt2 and operator mono. Wesbos.com/uses for more info!

[@joostschuur]

Talking head PIP looking great!

[@WesBos]

Thanks! Been working on it

[@VivekSingh-kx6ri]

Whats Vscode Font style called ? Is it Free men?

[@benfrese3573]

Thanks for the free therapy session!

[@WesBos]

We all deal with rejection from time to time

[@benfrese3573]

@@WesBos fr

[@ukaszzbrozek6470]

If someone use multiple wrapItObject he don't have to use object destructuring. Then it would be cleaner.

[@nicodindon7477]

Nice tricks thanks! I'm sure it can improve readability of few functions at work. The biggest difficulty with errors in JS to me is the lack of "custom exceptions". In PHP i was used to `throw UserAccountException()` then catch only this exception in the place i want. I never found sastifying equivalent in JS :/

[@WesBos]

You can do this by passing a bound function, or passing the arguments as a second param, Then instead of passing in a promise, you pass in a function that can be called inside the try/catch. function wrapItButCallItToo(func) { try { // call it here - this will catch thrown errors too func(); } catch(e) { console.log(e) } }

[@nicodindon7477]

Thanks a lot Wes.

[@josemarin359]

Best solution to manage async and promises is to use js-awe library

[@ahmadmuslih]

at 16:52 how can you open the code in that mode? Great video btw

[@xinaesthetic]

I feel like ’settle' might be a better name for 'wrapIt'.

[@WesBos]

Yeah wrap it isn’t a good name

[@NRNR-tw2fh]

Thank you 👍👍👍

[@farqueueman]

I know that theme from a mile away. Cobalt2.

[@ejnshtein]

So, basically, we add sausages from Goland to JS 🤔 Okay, I'm in.

[@WesBos]

Sounds delicious. I’m in too

[@AbdurRahman-rj9bv]

Awesome

[@markridgway249]

should have had that On Air light on

[@WesBos]

Good call. I’m hoping to automate it

[@jaspreetsingh2379]

Javascript added a new feature called error. cause. That helps with debugging

[@sahassaurav4144]

I use async await with .catch() and to handle thrown error I use global try catch block

[@WesBos]

Cool - global you mean like wrapped around your entire set of logic for handing something like a route or controller?

[@sahassaurav4144]

@@WesBos try { const value = await doSomething().catch() } catch() { // Handle thrown error here }

[@omomer3506]

Yes these videos

[@WesBos]

Ya like?

[@omomer3506]

Dude, your podcast and your videos are the only reason i don't cry about feeling like a complete idiot, you simplify things even for us mortals

[@lethienngan]

+1 thumbs-up +1 follower

[@DioArsya]

niceeeeeeeeeeee

[@TamanKodeKode]

when Go engineer write JS

[@FredoCorleone]

I don't get why try/catch is uglier than a custom method that wraps the promise and returns a tuple data, err. IMO the latter is uglier, please try to convince me the Go way is better.

[@TheNoim]

// There is a good reason why I prefer the throw approach: // Most of the time when I write a server-side app, I don't really care about the individual error. If something fails while executing my "action" (for example in a request), it should just throw. My server framework of choice probably has a built-in error handler. // This is why I don't like it when libraries use the go approach. If an action fails, it should fail. // Here is an example: someserver.get("/some/route", async () => { const someData = await someDb.getData(); // If this fails, the framework error handler should just deal with it. Frameworks like Nest allow you to customize the error handler, which is really nice. // Do something with the data return someData; }); // With the go approach, I would need to do something like this: someserver.get("/some/route", async () => { const [error, someData] = await someDb.getData(); if (error) { // I don't care about the error throw error; } // Do something with the data return someData; }); // A hybrid approach for me would be something like this: class Result { constructor(private readonly _error, private readonly _data) {} get error() { return this._error; } get data() { return this._data; } orThrow() { if (this._error) { throw this._error; } return this._data } } someserver.get("/some/route", async () => { const someData = (await someDb.getData() /* Returns Result type **/).orThrow(); // Or const { data, error } = await someDb.getData() if (error) { // Do something with it } // Do something with the data return someData; }); Even better, everything could be usable: // Go style via promise extension interface Promise { goStyle(): Promise; } someserver.get("/some/request", async () => { // .goStyle() is optional. You can still use the default try/catch const [error, data] = await db.classicGetData().goStyle(); if (error) { throw error; } // Do something return data; }); // Rust style via promise extension interface Promise { asResult(): Promise; } someserver.get("/some/request", async () => { const result = await db.rustStyleGetData().asResult(); if (result.error) { // do something return } // Do something return result.data; });

[@d33bo67]

back in the Nodejs days lol

[@soniablanche5672]

You can technically get both data and error at the same time with promises too, by using Promise.allSettled(). This function always resolves, so you don't need a catch block for it.

[@WesBos]

You should watch the whole video!

[@FadlySansan]

@@WesBos lol

[@spondoolie6450]

method 3 💪

[@indrajitsarkar3169]

Promise.allSettled way is pretty cool, definitely going to use.

[@AshishVermaCS]

For someone like me who was using await my promise().catch(errHandler); This is gem - thanks for sharing Wes