Promises: Error Handling, Aborts, and Helper Methods - Part 2

in in what case are you firing off

resolved that you've done it. And often developers don't realize this because you're working with a local database the static ones on capital p promise.

It's close. So they both you're right in that. They both will resolve as soon as the 1st a what's called a tuple. And a a tuple is like an array that has a known length and a known type.

any is success only.

value. The first Node. Again, I don't know. Like, promises. So you have a promise. It goes off and, like, I I'm sending,

I'm trying to trying to twist into work in here. Well, if you're out there and you're listening to this and saying, guys, I have the perfect use case for this.

Mhmm.

Race will return the rejected or I'm gonna start searching for cool. So it sends a fetch request off to your API.

promise is is uploaded. So async await error handling strategies because

Do you wanna guess what those are for unless you've used them yourself? Do you know what the difference is? I you know what? Just looking at these, I would say doesn't

But

And as soon as somebody clicks one of those buttons, then you wanna continue on with the rest. So on with the rest of your thing. Most commonly being, like, So all was initially rolled out when we got promises.

maybe you have 2 different APIs, and you're sending data to 2 because you you wanna have, like, double backups. Right? And you only care returning values from a function that may not be a promise, it just turns your static data. Like, promise Scott resolve 42, They don't allow you to to pass in a time out. Right? Or you have your own promise based function, The difference being that

for specifically, because I have used any, but I've never used race before. And either way, I these aren't things I need to reach for very often.

maybe okay. Here's what I'm gonna guess. This is this is just totally off the wall guess for me. I'm gonna say they both but still chain a dot catch onto that bad boy. So that way, you don't have to wrap the whole thing inside of a try catch. I don't know why, but try catch feels so obnoxious to me. It pnpm you like, it then reindense my code all by 1. It feels like it takes up a lot of space. That's one of those ones where it's like, I will use the Scott catch method, and I will use await

Well, let's get into the 1st section of this episode. We're gonna be talking about canceling

you can call me up and say, hey, Scott. Come back.

So that is entirely

At any given point,

Yeah. Cut it out. Stop doing what you're doing. I found the cheese in the fridge. We don't need any more cheese. Or, Hit us up on YouTube. Drop a comment in the video below this video. I wanna hear what people are using race

up to you.

And you can return

with the resolve or reject methods at any time as well.

Okay. Now you've you've sent off a second You might only care

Why would you reach for an abort signal? Because that's not something I feel like I've ever had to do.

Thank you. Thank you for that. Yeah. Yeah. Well, let's talk about some of these additional helpers for promises. You may have seen some of these, like, promise Scott

if you have a a type ahead that is sending off fetch requests. So you have a search Bos, you start typing in cool, and then you stop for a second, and it goes, because Century is going to tell you when your promises are thrown, maybe when they're you have an uncaught reject in one of your promises that you weren't expecting.

Your database is somewhere different than your actual user. There could be real world things. So as you are typing, it turns it into a promise that immediately resolves to 42.

and on local hosts, and there's no latency at all. But you get into real world conditions.

to get the value out of a promise, typically.

inside of Wes you're going to await a promise.

However,

to whatever is happening with that dot catch. Now you can also use a try catch statement to wrap your await

one thing that I learned from Wes a little while ago JS that you can mid mix these approaches where you can You can do all kinds of stuff with it to ensure that your UI JS My name is Scott.

accordingly stops trying to resolve the other promises? that any resolves once any of the promises or you're sending me to the store. Right? The promise is that I'll return with the stuff.

you can console log the error. You can throw it to Sanity.

then

Let's talk about error handling within promises. Now typically, if you're chaining methods on a promise, you can always add a dot catch method that takes a callback with the error that gets returned there. So you've seen that Wes it has a callback with an e or an error,

on a So I think I think await kind of did away with the need for most of this stuff because I have a really good promise dot race example. So often when I don't know how people use APIs,

You basically have control over the full process

in order to to show them. So you'll catch the reject in that in that case. So database work,

I've tried if you want to add a time out One kind of way that I've been writing a lot of my promises lately is this idea of writing a wrapper function around your promises Yeah. I was I always was a big fan of Again, we'll talk about them a little bit more in the next episode. It's called deferred, Like, for example, if you're uploading 7 photos,

throughout which you're working with your promise.

Yeah. Inside of a promise, Handle the bad case first, and then you have your your happy path. Gotta have your happy path. So,

And that's great if you're trying to, like, keep the chaining or you're

but you want to still maintain the whole promise API because everything else you're working with is a promise.

That's

Alright. Talk to you later. Peace.

you're you're passing something to a function that expects a promise and not just a straight up value.

you might have

that's the same thing. But if you need to turn a function

And I I realized I had used them a couple times JS if you are to something that has a promise, fulfilled value. So promise after 5 seconds. If this thing doesn't come back with data or after 5 seconds, if the user hasn't clicked this button, then we need to do something yeah. Yeah.

if you have an async function that returns 42, maybe after And both of those will resolve as soon as the first which is fulfilled or rejected, which is You get the result back. You wanna first check. Wes there any errors saving that item to the database? as soon as somebody clicks one of those buttons.

a cache API that either fetches some data and returns to you or it would just pull it up from the cache and return it to you. So by returning promise dot resolve with some data, queuing and concurrency and running Yeah. Promises in series and whole bunch of libraries that are helpful for working with this type of stuff.

And that's a little bit tricky because if you press, like, the done button, but if you want the actual error on the next line, yeah, that's I have a little YouTube video I'll link up here detailing

And I think over time, you just kind of get feeling for which way you like to do what, and that's that's typically

But there's a really popular library out there called await to JS, And that can be handy JS if you want to Now there is also I can confidently say I've never used either of these. Yes. I'm curious if you ever have either. There's promise dot any and promise dot race.

should be the first in my logical brain it's a good way. You can yeah. You could reject a promise at any time.

one second. And then if if the result is empty, then it it timed out. And if the result is there, then then it worked.

what you can do is you can say, and a settled is a reject or a resolve, whereas promised that any will return the 1st And then Node day, my servers my server crashed.

run a try catch

and will return return from that function functions if you wanna pass them to something else. Like, for example, I have

the actual data. And that's really nice if you need to first deal with an error before you go you don't have to wrap it or anything. You simply just pass the signal of abort signal Scott time out, 500 milliseconds, and then that thing will reject then render an error page. If not, continue on with the rest of the page, maybe render out the user page.

I you know, just even saying this yeah, we're gonna continue our our talk on promises. And after this one, I think you'll have a a great idea about a little bit more in terms of how to use them beyond just the basics. So my name is Scott Tolinski.

how it feels for me.

Like, what are people actually using this for? And you know what? This is such a good example of of what it's used for JS that that that's an example of when you would want to put the logic inside of a promise.

as a feeling things because you can typically write most of the stuff you're gonna do with any of these approaches.

the different A good example would be rejects, promise Scott race will return the 1st settled value, you can like we said in the last episode, you get your resolve, you get your reject methods, and you can do whatever you want with those. And often, what that in includes is you have some logic inside of your promise that says, you might have 2 successful promises, they're all aborted. Right? You're you're you're out of luck. So all settled will return to you an array of the results I didn't catch the error. Yarn. My entire server crashed,

a function that you can wrap your promises in. And then it will return

when you're doing a promise. Like, oh, if this fails, take care of the failure first.

you you try to save an item to a database.

Yeah. Oh, I learned a thing or two. Last thing we have here is the capital p promise

makes me wonder why, await a variable result,

I'll just go and get up search and search for that API and see. I'll just add to scroll through 15, 20 different code examples.

then, again, it's it's out of scope. You don't have access to it. You gotta do some weird variable things.

this approach. I think it was And as that fetch request is in flight, you just type I f y f I.

you know, dot catch or even like, it feels like the error

to you an array. 1st item being the actual error, 2nd item being to the server that for Coolify. Now you have two fetch requests in flight and it is not guaranteed that they will come back in order clicking the button 6 times and it doesn't work, then then reject or after. Pretty common is you want to put a 5 second time out that's where you use reject and resolve methods, that returns and pass it a like, a time out function that will throw.

in every function.

And I've always wondered, like, why are those there? You know? Like, what are those 4? in JavaScript has 2 static methods on it. So Scott reject request

makes way too much sense. I've never used await to JS or any of this stuff before, but I like the way it reads when you look at the code.

Then if it didn't fail, we know it succeeds. Like, logically, the order of that themselves

And back in the day,

I in my TypeScript course, we create a function called collect and learn how to, like, use generics to type something that is so abstract.

promise dot race, pass it your original promise function, a little annoyed to me that that's it's called fulfilled or rejected. Shouldn't that say resolved or rejected? and this will just give you

Love that. Hey. Love that.

I'm trying to wonder, like, who popularized this in Node. Js land? I think some of the even the Node APIs that are callback based It was a fetch request

Yeah. Yeah. It's it's it is interesting because you like you said, like, you do it different ways. To me, it's one of those

If if so,

const result equals await And then that's beautiful because It makes sense. Either or or not even throw. You could just resolve after

And, you know, you have to add a timer to it, and that's annoying. That's one of the nice things about fetch where it's built in, but not everything is a fetch. So promise dot race, method that you have there. So I would say I don't know. Unless you I wanna abort everything, but that promise not one is better than the other. I use all of them. Sometimes I try catch. Sometimes I catch is good. Often, a mix and match is really good. And then if I'm doing specifically, when I do a lot of, like, Node. Js multiple promises? Maybe, like, if you had a promise that was waiting for a click on multiple buttons. Mhmm. So you might have, like, 6 promises that are waiting for clicks on 6 different buttons.

that is resolved. But if you push the cancel button, that is a reject. Often, you could just wire those up directly to an ad event listener,

Wes have this idea called an abort controller.

but, essentially, promise that with resolvers will give you the promise, but it will also give you the resolve and the reject methods outside of the promise instead of inside of the promise callback.

if there's no response back after 5 seconds.

And you create an abort controller, and and then you're able to control that fetch request from wherever you have access to the abort controller method. It's a little bit more complex than simply just rejecting because you do want to also cancel the network Wes, and that will take care of all of that stuff for you JS well as there's a built in signal for simply just doing a time out. Because if you wanna set the time out of a fetch function, And whenever my server crashes, I get a little Sanity alert, and I get an email about it. And I logged in. I thought, one is finished.

Also, we have promised that with resolvers.

buttons on an example somewhere where and you're up and running. So that's another way you can cancel them. And then also in fetch land, if you are firing off a second fetch request, you need to make sure that you abort any other requests that are currently still in flight. So that's where you'd wanna use an abort signal.

pass those, like, pretty much, like, succeed and Vercel, I'll reach for the collect or await to JS of if they were all successful or not. They'll give you an array of 2 types of data. Each item in the array will be will have a status, So for example, but then you have to reimplement the time out functionality So with this idea of I call it collect.

I promise you're gonna have a good idea. Yeah. Okay.

helper methods, and more. So, return once the 1st promise resolves. I would imagine that maybe any also resolves the other promises where race

Oh, welcome to Syntax. In this episode, we're gonna be taking a part 2 to our series on promises. And in this video, we're gonna be talking about air handling. We're gonna be talking about aborting a promise,

And because it was unhandled,

and they warned for years that they're gonna turn it off. And I said, Tech.

why did my server crash? And I looked at the century error.

fetch Wes. But that happens, and Sanity was able to It wraps them up into 1 mega promise. Yeah. And it waits for all of the promises to be done. And if one of them takes 1 second and one of them takes 10 seconds, you're gonna be waiting the full 10 seconds before you get all of the data. Right? But if one of those were to reject, but there's no way to get that data that something has been sent to one of them. Right? that will internally It's been so long since I've worked on it, but, yeah, it was always give you the error first, then the data, and that forces you to think, okay.

I can tell you, I, myself, where do we at here? 23 minutes? Yeah. That's enough for a part 2. Hopefully, you learn a thing or 2. On pnpm Monday, we have the 3rd although, like, just you could pass in multiple selectors to something like that as well. I don't know. That's a contrived example that have the option to pass it in. Like, you're using somebody else's API.

tell me exactly what happened, and I fixed it in, like, 3 minutes. So check it out, Sanity Scott I o. Check it out.

Node used to have this thing called

that if you have issues with your promises, you're gonna wanna check out Century installment of the series coming out Wes we're gonna talk a little bit more about which is unreal that, were like that.

Well, I promise you, my name is Scott Talinski, and I'm from Denver. With me, as always, is Wes Bos. What's up, Wes? Hey. Not too much. I promise

Sick.

Node used to catch your uncaught promises,

Promise Scott all settled. What is the difference between promise all and promise all settled? So I've been a big fan of this approach. I have 22 statements on this. 1 Yes. We we should take your collect and turn it into a library, and we can call it collect call. That's good. That's a good joke. Oh. Yeah. That's great. Thank you. Yep. And, second,

or why I should say the promise itself

the promises have resolved.

And it usually gives you essentially an array of the values that come back from those promises.

once

fulfills

promise dot all accepts an array of promises.

And what it will do is it returns

Now I am curious, Wes, because I know you know more about this than I do.

complete.

all, which

regardless you could do try catch, and then you gotta update variables outside of the scope. That's kind of annoying. You can use the away and dot catch, and dot resolve.

you might want to do promise that all and upload all 7 concurrently all at the same time. However, if 1 of them doesn't upload because it's too large or it's the wrong file type or something like that, The other 6 that may have been uploaded abandon all ship as soon as one of them breaks, you probably want all settled in most cases. Yeah. And then from that, finally, you mentioned this last show of it being really handy JS if you want to do something after it resolves or rejects, like turn off a loader, implementation.

then you can use finally, and that will run-in either case.

it it's rejected, and immediately you go straight to the catch when you're you're chaining. Right? So that's kind of a pain if you do care about the successful ones, but not the one that was was failed. Right? it could crash an entire server just with a a single,

anymore because that I had not been or Node. It wasn't a yeah. It was a fetch request, but it was a post. So I was posting some data to a third party service. That service had an outage.

correctly or are are still in process, that abort controller itself has what's called a signal. You pass that signal to a fetch request,

Maybe not. And then on successful ones, you'll get a value property, which has the data that you're looking for. And then the errored out ones, you'll get a reason property, which will have whatever is passed to the rejected the whole thing is

And the downside to that is if one of those values given these use cases, in express JS and Deno JS land, the way that it worked is your callbacks would often give you the error and the data, and you would either have the error or the data. And that was really nice because you could first check if there was an error, and if there's not, you can continue on with the actual data.

is over. So promise that all takes, like you said, an array of promises.