Wes posting on Twitter, and then merging all the Twitter feedback from programmers into KZfaq posts like this is the new ChatGPT. 🙌

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.

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.

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

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

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!

Always at the top 👌 Awesome video 👍

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

great video! Was exactly what I was looking for

Fantastic video! Thank you

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)

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

Thank you 👍👍👍

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.

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

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?

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

Thanks for the free therapy session!

Awesome

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?

Talking head PIP looking great!

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?

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

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.

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

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 :/

Whats Vscode Font style called ? Is it Free men?

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

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

I know that theme from a mile away. Cobalt2.

+1 thumbs-up +1 follower

Yes these videos

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

niceeeeeeeeeeee

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

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

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

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

should have had that On Air light on

when Go engineer write JS

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.

back in the Nodejs days lol

// 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; });

method 3 💪

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.

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

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