Async Await is heaven... until error handling comes into play. Learn how to avoid try/catch hell when writing async JavaScript code. #shorts #js #programming
@@claudeb.3473deactivate lint? For me lint does nothing but helping with some details with the code. I use intellij editor. I can code without lint very well. But I maintain it active cuz it's kinda cool. But totally unnecessary for the code to compile. Of course the intelijj editor helps to get the job done.
@@NightstalkerKK Well, if you go down that rabbit hole and make an Either-monad that can be either DATA or ERROR you'll get something very simmilar to Promises (which are basically monads ), and I'm not sure why someone would want to do that. That's not a sarcasm. I want to know why someone would want to do that.
@@RicardoValero95 No, havn't tried fp-ts yet, just general Ether monad. It can be Maybe (or Option) monad depending on how you look at it. I'm not a computer scientist so feel free to corect me
No, he is not. He suggests incorrect solution. Simple solution: async func() { try { const a = await step1(); const b = await step2(a); const c = await step3(b); return a + b + c; } catch (e) { handle(e); throw e; } }
@@davguev his error handling is wrong because in case of first error "a" variable is still undefined, so step2(a) makes no sense. The same is for "b" variable. My refactoring fixes this problem
rust developers can just put ? in front of the function. If an error occurs, the function halts and returns the error. It's awesome for those that understand it, a nightmare for someone unfamiliar with rust lol.
Is that also the case for async code in Rust? Async is inherently different. JS does have the ? on objects to continue if something exists, otherwise returns undefined, which sounds similar to what you're describing.
@@MrMudbill interesting. Thanks for that, I'm still really bad at js. In rust, we have enums that specify a limited number of data types. These enums can wrap other types of objects. There are no exceptions in Rust. Everything that can return an error is represented by an enum called Result. This enum can be Ok or Error, A is the type of the object that represents the succesful result. B is the type that is returned when something goes wrong, can be a string with a text like "failed to do x", but often it's another enum representing all kinds of possible reasons for an error to occur. The good thing about this is that every possibility is already pre-compiled and optimized. ? just unwraps the Ok or return Error for the function. Async rust doesn't change the return values of the functions.
Not quite… the tower of doom is necessary since without it your code would break and stop executing (without a catch) . With this approach you can decide what to do with the error if you wish to but your code won’t stop running. Of course you could use top level try catch but that takes await the granularity of handling the errors which this approach provides.
@@TheDaidalosKvintus How does a top level try/catch work with multiple? I would assume if one crashes the rest stop processing, otherwise you'd be catching multiple errors if more than one breaks. So I don't think a top level try/catch actually works
And then you will end up with tower of ifs, when each function depends on previous results You've just writed try catch using if statements nothing changed What you can do is catch them all together And make specific errors for each function and then switch through errors in catch block if you need to perform something for each error case
That is also the same thing, you've just shifted the try catches into ifs inside a catch. My solution would be to have a single function with a try catch, it would call a function passed to it and return null or data based on exception. Basically, a wrapper function. So now all you need to do is call this function and pass it whatever async function you have and it will either return null or data and you can check it easily.
To use the "awesome" function in typescript, you can do it like this: async function awesome ( prom: Promise ): Promise { try { return [await prom, null]; } catch (error) { return [null, error]; } }
@@bash7279 But then you end up with stuff like async function foo() { let [res, err] = await bar(); if (res) { let [r2, e2] = await baz(); if (r2) { // ... } } }
@@LoveLearnShareGrow Huh, Wikipedia actually has a pretty concise definition for it: “In functional programming, a monad is a type that wraps another type and gives some form of quality to the underlying type.”
@@redpepper74 that seems like a very ambiguous definition. Is a monad a value of a custom data type or is it the data type itself?. Are monads comparable to Javascript objects since they can "wrap" primitive values? What "quality" is given to the wrapped object/value? Does this ambiguity exist because monads are meant to be versatile and therefore it's an umbrella term?
Tips: - Make the function take a promise as a parameter - use "catch" method of the promise - Call this function "to" function to (promise) { return promise.then(data => [null, data]).catch(err => [err]) } const [err, data] = await to(fetch(/*thatUrl*/)) Notes: Dont need to have an async function or to use try-catch; its reusable for any function returning a promise; its a oneliner in a oneliner \o/
Such a quality of life improvement. I read this in an article once, when I was just starting out, and started writing it, just waiting for the other shoe to drop (I had to defend it before my boss, who was skeptical at first, even though he hated try catch and longed for the async.js days); cause why wasn't everyone doing this? No regrets!
This is creeping toward a design pattern of functional programming, where functions take in an error state as an extra parameter, and also return an error state within the return type. If there’s an error passed in, it’ll just early return the error. If the function itself encounters an error, it’s included in the returned payload. Otherwise, it just returns the expected output. This way, you can chain functions in any order and ensure that an error will get caught early and allow downstream functions to skip expensive logic. Once I learned this pattern, I started using it everywhere. So useful.
most people say its a hell , but its necessary to not be lazy with errors. GoLang is protecting us from ourself. Errors are values so take advantage of that.
reminder that when Generics arrive, you'll be able to be ultra lazy and do stuff like this without any interface conversion func catch[T any](val T, err error) T { if err != nil { log.Error(err) } return val } and call it like: var x int = catch(strconv.Atoi("lol not a number"))
Looks a lot like Andrei Alexandrescu's "Expected" from his 2012 talk. It's a variant that stores either the value, or an exception. But C++'s operator overloading makes it more convenient to use.
@@sayamqazithat's not an excuse, there are plenty of examples of languages that have withstood the test of time much better because they were built on solid principles
@@fbarnea but again the guy building the language didn't foresee what it was gonna be used for. And from what i recall he did it in a couple weeks. Nobody was expecting full fledged apps were gonna run in browsers. But once the web exploded it was not easy to backtrack and fix the issues as a lot of code was already shipped. this is exactly why broken html actually renders somewhat fine in the browsers to this day.
@@sayamqazi that doesn't contradict the fact that the language is broken. What you are saying just further solidifies that it's broken and not fit for purpose. Yet anytime someone says this countless fanboys feel the need to contradict.
@@fbarnea but where did i contradict. i just extended the discussion and made a point that things are not as bleak as some people make them look like. after all it has been serving it purpose to billions of users every day. it has added hundreds of billions of dollars of value to the economy not out of nothing. yes it needs to and can improve but people do exist on each side of the extreme. javascirpt is literally the goto langauge to take shots on for many people.
if you have the same handler for all those functions why you can't put a try-catch over that function you are writing? that's ok when your function can throw something, that's just natural js behavior (rather than onError callbacks)
@@buraky16 talking about frontend - Elm is good and friendly. On BE side it's either f# (if you want to have an ability to retreat into OOP sometimes) or haskel (if you want to go full hardcore).
hi, if you have sequence of promises like your example, i would use promise.all() and put there all the previous promises as args and the inside one try catch. LOL ;) Next video Top level await in browser and nodeJS ( its is now available in FF and all chromium browser) ;)
@@asm5087 No. Because is not the correct way. If one promise dont depend on another then you should use promise.all. I recommend read mdn to see the difference.
this is what's called an iCallback, very useful when setting up anything with complex error handling. I've used it for android projects before and it's a blessing!-
@@NightstalkerKK pretty sure you can find one but in a nutshell you can catch errors with a catchError operator. If an error occurs in a pipe it just flies straight to the next catchError, its a higher order operator like switchMap and you can gracefully recover from it. If an error is not catched it errors the whole pipeline (dont forget that multicasting segments the pipelines), and shuts down the subscription.
@Pasha Bolokhov that really doesnt matter, rxjs is a low level library, a set of tools to solve async programming. While promises only hold one future value, observable hold N future values. And actually a lot of things support it because its popular (Angular, Svelte). The "integration" you're talking about is just whether or not that something has built in solution to handle subscriptons, which is really only needed in templates. And there is an RFC to include observables as native JavaScript constructs :) Protip: try to keep manual subscriptions as low as possible and instead create pipelines, taps, and utilize multicasting and higher order operators
could you not just put multiple async calls in one try catch like this: try{ const a = await asyncCall() const b= await asyncCall() const c = await asyncCall() }catch{}
You could, but if a function throws an error here, the following function calls won't get executed. You'd have to put each function in its own try/catch, which is where the video starts from
I agree; I use a single try-catch when each operation uses the output of the previous one. If the first operation fails, most of the time it doesn't make sense to run subsequent operations without inputs.
How about using Promise.all([asyncCalls]) (or Promise.allSettled([asyncCalls]) if the calls do not depend on each other). This is better then chaining awaits
A fine pattern for sure (and not specific to async). But a more idiomatic approach would be to switch on error type, wrapping the entire block in a single try/catch.
How good practice is it to append catch with await? await something().catch(err=> ()) Can anybody tell me about this, it looks to be not a good practice
If you can actually handle and recover from the error then it's fine. if you just throw away the error and pretend it didn't happen, you're in for a surprise and a hard time debugging.
In my opinion it's the best way to express that specific behavior. Just make sure you actually want and can handle the result from either something or the catch body result if it isn't rethrowing in that body. Keep in mind, async/await is defined in terms of those Promise methods: there's no issues crossing the streams here.
If you want an error to break the sequence of events you should probably be wrapping the multiple await calls in the same try / catch block ? You can always check the error instanceof if you need to know which error type occurred. That's probably what I would do.
Protip: Avoid the pyramid of doom by never indenting your code 🤙.
Why stop there? Eliminate errors by disabling lint rules and git hooks. Some of our developers are getting a lot done using these techniques.
Bruh
@@claudeb.3473deactivate lint? For me lint does nothing but helping with some details with the code. I use intellij editor. I can code without lint very well. But I maintain it active cuz it's kinda cool. But totally unnecessary for the code to compile. Of course the intelijj editor helps to get the job done.
@@sertanojouniversiotario9599 What version of is_joke() do you have?
@@PMA65537 I think we'll have to run $ bad_joker --v
Basically you made Javascript looks like Golang Lol.
yeah golang ftw, peak of simplicity
and Rust
@@okie9025 Rust does not do error handling this way
@@xetera it uses Result to wrap errors with return values lol. You can even do ".unwrap()" to throw the error and stop execution.
@@okie9025 using a Result enum with functions for handling the data is much more pleasing than the golang way of checking for nil everytime lol
"a sink"
"a weight"
k
cant believe I didn't spot that
didn't Wes Bos have this on his first slide in some talk once?
😂😂😂
A where
How did i not spot that.... Am i alone here?
My life is pretty dull and uneventful, so this was the best 45 seconds of my life.
It's not. You decide what an event is four you and what not.
add some css to ur life.... or import Bulma
const EventEmitter = require('events') ;
const event = new EventEmitter () ;
event.on('event', message => console.log(message) ;
While(true) event.emit('event', 'You're having a "eventful" life (literally)') ;
You got 100 likes so now your life is pretttttty good
your life is undefined, and the undefined life is not worth living
Congrats! You one step closer to using monads for error handling
We'll get there someday
Do you have an example of this error handling implemented in javascript? i would like to look at it, thank you
@@NightstalkerKK Well, if you go down that rabbit hole and make an Either-monad that can be either DATA or ERROR you'll get something very simmilar to Promises (which are basically monads ), and I'm not sure why someone would want to do that. That's not a sarcasm. I want to know why someone would want to do that.
@@alexeyl1739 aren’t you describing TaskEither from fp-ts (I’m not saying they invented it)
@@RicardoValero95 No, havn't tried fp-ts yet, just general Ether monad. It can be Maybe (or Option) monad depending on how you look at it.
I'm not a computer scientist so feel free to corect me
the best 45 seconds of my life
That's what she said
*Almost* the best 45 seconds of my life, second only to making love to my wife
You and me both.
True.
@@namansinghal1892 u.u
And we're coming full circle.
😂
I've been asynchronously awaiting for this and finally this video showed up
Promise fulfilled.
@@floobertuber*resolved
Have you heard of golang, or monads 😅
This reminds me of a quote:
"Errors are values"
I guess that makes me very valuable
@@adrycough bruh
*laughs in c*
In Javascript, errors are objects, and objects are containers of values, and therefore data
Holy shit, most youtubers would have turned this into a 10 minute monetized video. You are amazing.
No, he is not. He suggests incorrect solution. Simple solution:
async func() {
try {
const a = await step1();
const b = await step2(a);
const c = await step3(b);
return a + b + c;
} catch (e) {
handle(e);
throw e;
}
}
@@ihateidiots9484Implying you want the same error handling for every step.
@@davguev his error handling is wrong because in case of first error "a" variable is still undefined, so step2(a) makes no sense. The same is for "b" variable. My refactoring fixes this problem
rust developers can just put ? in front of the function. If an error occurs, the function halts and returns the error. It's awesome for those that understand it, a nightmare for someone unfamiliar with rust lol.
Is that also the case for async code in Rust? Async is inherently different. JS does have the ? on objects to continue if something exists, otherwise returns undefined, which sounds similar to what you're describing.
@@MrMudbill interesting. Thanks for that, I'm still really bad at js. In rust, we have enums that specify a limited number of data types. These enums can wrap other types of objects.
There are no exceptions in Rust. Everything that can return an error is represented by an enum called Result. This enum can be Ok or Error, A is the type of the object that represents the succesful result. B is the type that is returned when something goes wrong, can be a string with a text like "failed to do x", but often it's another enum representing all kinds of possible reasons for an error to occur.
The good thing about this is that every possibility is already pre-compiled and optimized. ? just unwraps the Ok or return Error for the function.
Async rust doesn't change the return values of the functions.
After the function arguments but yeah... And I promise that getting used to it is easier than learning exceptions
So from tower of doom with try/catches to tower of doom with if/elses?
And to tower of doom with functions for every "step" and try catch inside
Not quite… the tower of doom is necessary since without it your code would break and stop executing (without a catch) .
With this approach you can decide what to do with the error if you wish to but your code won’t stop running.
Of course you could use top level try catch but that takes await the granularity of handling the errors which this approach provides.
@@TheDaidalosKvintus How does a top level try/catch work with multiple? I would assume if one crashes the rest stop processing, otherwise you'd be catching multiple errors if more than one breaks. So I don't think a top level try/catch actually works
And then you will end up with tower of ifs, when each function depends on previous results
You've just writed try catch using if statements nothing changed
What you can do is catch them all together
And make specific errors for each function and then switch through errors in catch block if you need to perform something for each error case
Early returns are nice
That is also the same thing, you've just shifted the try catches into ifs inside a catch.
My solution would be to have a single function with a try catch, it would call a function passed to it and return null or data based on exception. Basically, a wrapper function. So now all you need to do is call this function and pass it whatever async function you have and it will either return null or data and you can check it easily.
Return error as value is amazing. I love Rust.
To use the "awesome" function in typescript, you can do it like this:
async function awesome (
prom: Promise
): Promise {
try {
return [await prom, null];
} catch (error) {
return [null, error];
}
}
You still have to if (data !== null) every time if you want your program to have any decent behaviour though.
You can use
data && console.log("data isn't null")
For a one liner or just
If(data) {}
So it's just more cleaner than try catch
@@bash7279 What if your data can be 0? What if `false` is a valid data? That's why it always has to be !==
@@cat-.- Well, if (data !== null) is still technically one liner
@@bash7279 But then you end up with stuff like
async function foo() {
let [res, err] = await bar();
if (res) {
let [r2, e2] = await baz();
if (r2) {
// ...
}
}
}
@@0xlogn you can use guard pattern:
let [data, err] = await step1()
if (err) return err
let [data2, err2] = await step2()
...
So imagine when we realise that we could be adopting a functional paradigm and we can live inside of a monad
Every time I look up the definition of monad, I forget it by the next time I see the word mentioned again.
@@LoveLearnShareGrow Huh, Wikipedia actually has a pretty concise definition for it:
“In functional programming, a monad is a type that wraps another type and gives some form of quality to the underlying type.”
@@redpepper74 Yup. That is extremely forgettable.
@@redpepper74 that seems like a very ambiguous definition. Is a monad a value of a custom data type or is it the data type itself?. Are monads comparable to Javascript objects since they can "wrap" primitive values? What "quality" is given to the wrapped object/value? Does this ambiguity exist because monads are meant to be versatile and therefore it's an umbrella term?
A monad is just a monoid in the category of endofunctors, what's the problem?
Tips:
- Make the function take a promise as a parameter
- use "catch" method of the promise
- Call this function "to"
function to (promise) {
return promise.then(data => [null, data]).catch(err => [err])
}
const [err, data] = await to(fetch(/*thatUrl*/))
Notes: Dont need to have an async function or to use try-catch; its reusable for any function returning a promise; its a oneliner in a oneliner \o/
Swift just got Async/ Await feature and now I'm getting this as recommended.
The solution I ever Needed.
Such a quality of life improvement. I read this in an article once, when I was just starting out, and started writing it, just waiting for the other shoe to drop (I had to defend it before my boss, who was skeptical at first, even though he hated try catch and longed for the async.js days); cause why wasn't everyone doing this? No regrets!
hello from golang:)
coming from c to javascript to python and recently to golang, I'll have to admit I like the way golang handles errors.
@@t_kon Yes, just handle all the errors omegalol
@@t_kon rust is another upgrade here
This is creeping toward a design pattern of functional programming, where functions take in an error state as an extra parameter, and also return an error state within the return type. If there’s an error passed in, it’ll just early return the error. If the function itself encounters an error, it’s included in the returned payload. Otherwise, it just returns the expected output. This way, you can chain functions in any order and ensure that an error will get caught early and allow downstream functions to skip expensive logic. Once I learned this pattern, I started using it everywhere. So useful.
Nice tips! This applies to Golang as well and it's error handling nightmare
Doesn't Go has default multiple return value?
most people say its a hell , but its necessary to not be lazy with errors. GoLang is protecting us from ourself. Errors are values so take advantage of that.
@@omarelkhatib150 True, but the downside is that our code can break fully on production
reminder that when Generics arrive, you'll be able to be ultra lazy and do stuff like this without any interface conversion
func catch[T any](val T, err error) T {
if err != nil {
log.Error(err)
}
return val
}
and call it like: var x int = catch(strconv.Atoi("lol not a number"))
@@Hyperlands How so?
Ok now I can add try-catch handling to my CV
Made this into the package resolvjs, with first class TypeScript support.
The difference is honestly astounding. I want to get better at writing clean JavaScript code thanks.
Looks a lot like Andrei Alexandrescu's "Expected" from his 2012 talk. It's a variant that stores either the value, or an exception. But C++'s operator overloading makes it more convenient to use.
Instead of attaching catch to each function, how about putting all await functions inside one try catch? Would that work?
Yes it does.. but you might find yourself using if else on the catch block or a switch statement in order to target a specific error
After finally defeating the Pyramid of Doom another foe has risen out of the depths of the binary system.
The Tower of Terror.
Tower of Try-err
We need more quick tips like this. Thanks so much
I like how there are pictures of a sink and a weight in the beginning
I'm starting to love programming. I enjoy it now. I understand it now.
how can you understand it? to me it seems like all the codes need to be memorized
@@scidja8567nah just Google stuff
i l;ove u jeff
Absolutely love the conciseness
I never thought about doing it this way but thats super clean! Definitely going to try this out
You know a language is broken when you have to implement a workaround to a workaround to a workaround.
or the language was made when there was no need to do gazillion things in the web-browser.
@@sayamqazithat's not an excuse, there are plenty of examples of languages that have withstood the test of time much better because they were built on solid principles
@@fbarnea but again the guy building the language didn't foresee what it was gonna be used for. And from what i recall he did it in a couple weeks. Nobody was expecting full fledged apps were gonna run in browsers. But once the web exploded it was not easy to backtrack and fix the issues as a lot of code was already shipped. this is exactly why broken html actually renders somewhat fine in the browsers to this day.
@@sayamqazi that doesn't contradict the fact that the language is broken. What you are saying just further solidifies that it's broken and not fit for purpose. Yet anytime someone says this countless fanboys feel the need to contradict.
@@fbarnea but where did i contradict. i just extended the discussion and made a point that things are not as bleak as some people make them look like. after all it has been serving it purpose to billions of users every day. it has added hundreds of billions of dollars of value to the economy not out of nothing. yes it needs to and can improve but people do exist on each side of the extreme. javascirpt is literally the goto langauge to take shots on for many people.
Teaching something so awesome in 45secs. You're on whole another level.
My guy basically created Result type.
That's why Tanstack query is so valuable in JavaScript
i remember my excitement when the feature was making its way to stable, so much code back then..
i'm not crying, your crying :'(
if you have the same handler for all those functions why you can't put a try-catch over that function you are writing?
that's ok when your function can throw something, that's just natural js behavior (rather than onError callbacks)
I think the point here is that this can be used when you have different handlers, even if he uses the same `handler` function in this example.
my second monitor:
this video
my first monitor:
try {
csvUrl = convertWixURL(csvUrl);
} catch(err) {
throw `Error converting url "${url}": ${err}`;
}
let req;
try {
req = await fetch(url);
} catch(err) {
throw `Error fetching url "${url}": ${err}`;
}
let txt;
try {
txt = await req.text();
} catch(err) {
throw `Error parsing text from url "${url}": ${err}`;
}
let jsonData;
try {
jsonData = JSON.stringify(csvToJson(txt));
} catch(err) {
throw `Error parsing JSON data from csv: ${err}`;
}
You just changed my life
You have to pass the promise as an argument in the awesome function, right? otherwise the code wouldnt work
Lmfao a sink a weight. Frikin love you bro. 😀🙌👑🔥🚀
Seeing this pattern being used in multiple modern libraries lately. 🔥🔥
You can pay for a course with MasterCard but “The sink and the weight”: priceless 😂
Get some functional programming patterns into your object oriented weekdays a passing by programmer
do you have any suggestion for a static typing functional language to learn?
@@buraky16 talking about frontend - Elm is good and friendly. On BE side it's either f# (if you want to have an ability to retreat into OOP sometimes) or haskel (if you want to go full hardcore).
hi, if you have sequence of promises like your example, i would use promise.all() and put there all the previous promises as args and the inside one try catch. LOL ;)
Next video Top level await in browser and nodeJS ( its is now available in FF and all chromium browser) ;)
Yes but thats a little complicated procedure for those who dont know about it, to be explained in a short video, dontya think
@@asm5087 No. Because is not the correct way.
If one promise dont depend on another then you should use promise.all.
I recommend read mdn to see the difference.
this is what's called an iCallback, very useful when setting up anything with complex error handling. I've used it for android projects before and it's a blessing!-
The last option is that classic Golang approach of handling errors, I highly recommend it 🤘🏻
Haha started to learn go lang after watching net ninja now tips from fireship ♥❤♥
or, embrace the power of RxJS and the observables! Join the dark side!
do you have an example of handling errors with rxjs, id like to look at it
@@NightstalkerKK put a catch inside pipe. Done
@@iM7SnaKe And you can forkJoin observable calls to avoid nesting calls
@@NightstalkerKK pretty sure you can find one but in a nutshell you can catch errors with a catchError operator. If an error occurs in a pipe it just flies straight to the next catchError, its a higher order operator like switchMap and you can gracefully recover from it. If an error is not catched it errors the whole pipeline (dont forget that multicasting segments the pipelines), and shuts down the subscription.
@Pasha Bolokhov that really doesnt matter, rxjs is a low level library, a set of tools to solve async programming. While promises only hold one future value, observable hold N future values. And actually a lot of things support it because its popular (Angular, Svelte). The "integration" you're talking about is just whether or not that something has built in solution to handle subscriptons, which is really only needed in templates.
And there is an RFC to include observables as native JavaScript constructs :)
Protip: try to keep manual subscriptions as low as possible and instead create pipelines, taps, and utilize multicasting and higher order operators
React hooks for async await. This is next level
Love how the core just says “welcome” 😂💀
This feels a lot like how Go works. Did you draw inspiration from it?
No, react hooks has the same format, kinda
And why would you? This blows up the number of things to have to consider at one point in the code, just for a syntactic nicety.
Me, who uses Rust: ?
rust ftw, just slap a ? on that bad boy
I literally studied this yesterday, nice refresher on it for me, thanks Fİreship!
Thank you for reinventing GO
I love the end of this video!!
could you not just put multiple async calls in one try catch like this:
try{
const a = await asyncCall()
const b= await asyncCall()
const c = await asyncCall()
}catch{}
yes but if "a" errors the next b and c wont run .... you might just want to handle errors for each
You could, but if a function throws an error here, the following function calls won't get executed. You'd have to put each function in its own try/catch, which is where the video starts from
I agree; I use a single try-catch when each operation uses the output of the previous one. If the first operation fails, most of the time it doesn't make sense to run subsequent operations without inputs.
How about using Promise.all([asyncCalls]) (or Promise.allSettled([asyncCalls]) if the calls do not depend on each other). This is better then chaining awaits
@@daheck81 Agreed, Promise.all() is far more efficient if the asynchronous operations don't depend on each other.
You probably should make a video for the rest of TH-cam(rs) on how to provide so much value in a so short amount of time... amazing
We've come full circle
A fine pattern for sure (and not specific to async). But a more idiomatic approach would be to switch on error type, wrapping the entire block in a single try/catch.
I'm still a super beginner but I just know this'll come in handy in the future!
probably!
I ran into both issues. THANK YOU
Just what I need, I just learned how to use async JavaScript probally and now this is my problem. Super useful
Your videos make me feel dumb. Thank you!
How good practice is it to append catch with await?
await something().catch(err=> ())
Can anybody tell me about this, it looks to be not a good practice
If you can actually handle and recover from the error then it's fine. if you just throw away the error and pretend it didn't happen, you're in for a surprise and a hard time debugging.
In my opinion it's the best way to express that specific behavior. Just make sure you actually want and can handle the result from either something or the catch body result if it isn't rethrowing in that body.
Keep in mind, async/await is defined in terms of those Promise methods: there's no issues crossing the streams here.
Love these short, to the point videos!
This was a godsend GODMODE PRO-CODER MOVE
MINDBLOWN!!
Any reason you want to try/catch every line separately?
someone finally said it
Because often times you want to handle errors depending on where / what occurred.
Hi^ golang
the quality of the videos... this man is a genius 👍👍👍
I dont know where all these coding shorts came from but I'm loving them
RxJS
fp-ts Either construct. Also see how Rust does it.
Okay this is the most useful video i e watched today ❤
came for the 45 second clips, stayed for the cheesy puns
first
Gold 🥇
@@Fireship 0:18 yep! this is what i do
Thank you Jeff🙏.Now my code will be clean🤗.
async function resolvePromise(promise) {
try {
const data = await promise;
return [null, data];
} catch (error) {
return [error, null];
}
}
Ahh, look at the new "Structured Concurrency" coming in Java. It solves this brilliantly.
Trust me, I felt that.
If you want an error to break the sequence of events you should probably be wrapping the multiple await calls in the same try / catch block ? You can always check the error instanceof if you need to know which error type occurred. That's probably what I would do.
this could easily be the most useful tik tok channel for programmers
Almost starts to look like elixir error handling
I usually don't subscribe randomly, but you are the guy didn't leave me an option to go without subscribe.
This was the most efficient program video I have ever witness
Love content like this, keep it up Fireship ❤
Alternative strategy: Unify your error handling and have all the requests in a single try-catch statement
This remembers me the Either that is a built-in feature in functional programming languages. Great content, man!
Reminds me of Node-style callbacks, function (err, data)
is it just me that actually prefers .then and .catch? - It just makes it clear in my mind what a function is doing and going to do if it errors
this is the video that i didn't know i needed but always did
There is a npm package await-to-js that does this. Love this concept.
So much info, in so little time
Man we need more tips like this ! its awesome
Being new to JS, I was scared of promises, async-await and tower_of_terror, you are LIFE SAVER !!!
Neat trick, this looks a lot like GO. You will then ofc have to check for errors like in GO after getting them back in the array.