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.
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!
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)
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.
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?
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
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 :/
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) } }
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?
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.
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.
// 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; });
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.
Наука
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.
haha that was a recent project! Used to be such a mess
Wes posting on Twitter, and then merging all the Twitter feedback from programmers into RUclips posts like this is the new ChatGPT. 🙌
😆
ChadGPT
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.
I was already using the Go way, but it is awesome to see that you can even expand it further.
Nice to see you posting so much on RUclips lately! Always quality content!
I appreciate that!
Always at the top 👌 Awesome video 👍
I found this extremely helpful. Thank you for taking the time to make the video.
you're welcome!
great video! Was exactly what I was looking for
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!
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)
Same thing with a lot of GraphQL libs - the Rust way seems more popular
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.
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 👍👍👍
Nice video. What is the extension you are using to log output right in editor? //?
Thanks for the free therapy session!
We all deal with rejection from time to time
@@WesBos fr
Great video. How do you highlight your single line comments with the yellow background?
It’s a plugin called better comments. You write regex rules and the apply new styles. I have them for “method, exercise, solution, problem…”
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?
Cobalt2 and operator mono. Wesbos.com/uses for more info!
Talking head PIP looking great!
Thanks! Been working on it
Came here just to say that your thumbnail game is strong with this video
hahaha thanks
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?
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
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 :/
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) }
}
Thanks a lot Wes.
at 16:52 how can you open the code in that mode? Great video btw
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?
Yep - I think I said that in the 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.
Whats Vscode Font style called ? Is it Free men?
If someone use multiple wrapItObject he don't have to use object destructuring. Then it would be cleaner.
what is this extension which is showing the return value preview?
Quokka
I know that theme from a mile away. Cobalt2.
+1 thumbs-up
+1 follower
I use async await with .catch() and to handle thrown error I use global try catch block
Cool - global you mean like wrapped around your entire set of logic for handing something like a route or controller?
@@WesBos
try {
const value = await doSomething().catch()
} catch() {
// Handle thrown error here
}
Javascript added a new feature called error. cause. That helps with debugging
Yes these videos
Ya like?
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
Best solution to manage async and promises is to use js-awe library
So, basically, we add sausages from Goland to JS 🤔
Okay, I'm in.
Sounds delicious. I’m in too
niceeeeeeeeeeee
I feel like ’settle' might be a better name for 'wrapIt'.
Yeah wrap it isn’t a good name
should have had that On Air light on
Good call. I’m hoping to automate it
when Go engineer write JS
back in the Nodejs days lol
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.
// 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.
You should watch the whole video!
@@WesBos lol
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