catchError Operator & Retry

[00:00:00]
>> Can we use the cache error operator?
>> I love that question. That the question was can we use the cache error operator? We can, right, in this situation, right. But we have to kinda changed the way cuz we implemented this because even if it's a 400 or 500, fetch does not throw an error, right?

[00:00:27]
It will simply say the response is not okay. But that doesn't mean we can't throw an error, right? We're well within our rights to throw an error in this case. So we can say throw new error. Something went wrong, right? Now we've thrown an error and we've created a bad thing for ourselves.

[00:00:51]
If one throws an error it's kinda throwing a apple pie in the air directly above you, you can throw an apple pie, you should be prepared to cache it, right? That not my best analogy, but we're gonna go with it. So the question was, can we use cache error?

[00:01:10]
We can, we just need to make sure that we throw errors is in the cases that we wanna deal with. So we have an operator called cache error, and instead of letting the observable error out, what it does is it allows you to cache it, right? And so we could say, return to basically that logic we had before.

[00:01:40]
I think that's an error object, in this case. We'll find out. I'll get yelled at if it's not. Well, so just cancel there too. All right, let's see that should do the trick. If not, we'll find out together and I'll look confused for a second. So we throw there, we haven't caught it mostly because we'll play a fun game.

[00:02:09]
Why didn't I cache the error?
>> You're outside.
>> Yep. [LAUGH] Yep. So it was on the outer observable. It's really this inner one that had the error. So that is a common case which is the inner one. Blew up nothing caught it it cascaded outwards. So you have to cache just like in JavaScript you have to cache the air while you're through the air, right, you can cache it I guess up the stack in JavaScript but cuz we are constantly airing.

[00:02:49]
Let's make it fail, cool. So yeah, we're seeing on the screen because we chose to cancel error. So you can see something went wrong. We're also seeing it there, not because anything blew up. Because we said we wanted to know. Right, so we can see the network failure but we can see nothing blows up in my code, it's simply we got the 500 back from the API which the API did 500.

[00:03:14]
But we recovered, we just put a notice and we gave it a shot. All right, so here's the tricky part now. We can have an API, it can work, we can show an error message if there's an error. Awesome. We can clear out the air too. I can say basically, we actually what I would probably do is if we try again, what I would probably say is.

[00:03:46]
Let's try that out, that should clear out the error in between fetches, so that work. Then we'll have one that should blow up every so often. And you can see when it works again, we clear out the error. What if we wanted to retry? How would you do this if you didn't have an observable?

[00:04:10]
You wanna say I wanna try four times before giving up, right, because we all know those API's but when that works 60% of the time works every time, right. What happens we wanna try a certain number of times but not perpetually maybe you do want to do perpetual.

[00:04:25]
But let's say we wanna retry it four times what would you do with just regular JavaScript
>> Sorry, you use a while loop
>> While loop and yeah you basically have to store in a variable, right? And you iterate over it and all that kind of thing, you could do that like everything in our JS is the thing that you could do because it's JavaScript.

[00:04:43]
You can also write your own virtual DOM too, you can do whatever you want. But when you don't hit your sprinkles, you don't come talk to me about it. One of the options that we have is this ability to retry, right? And we can say, okay, I wanna retry four times.

[00:05:05]
Alright I have that one in here too, so now it will go ahead and will if it fails for some reason it's gonna try it again, if you try it again and try it again. Now this one fails one every two times so ideally, we should see a success rate at this point.

[00:05:28]
And kinda see in the network did it fail, this one didn't. So you see it failed, and then try it again. Successful. Failed and try it again, right? It probably won't fail four times cuz this is a fake API that succeeds roughly half the time and science. But for the most part now we can basically implement retry logic incredibly easily.

[00:06:02]
Right? We have a pretty reusable piece of API fetching code, which will fetch it throw an error. If we get a four or 500, which a promise API doesn't do by default. It'll cache the error and we can choose what we wanna do with it gracefully. If it does if it gets through all four times, it will eventually hit this cache error and we can do something with it.

[00:06:22]
But otherwise, we can choose to retry it Mark.
>> For me cache error worked fine at the same level as exhausted.
>> Yeah, you know what it was? I think because I was literally counselling error. I was, that's an error I wasn't expecting, right. It should bubble up, right.

[00:06:39]
I think that's fair. Right, this one let's try it out. I think cuz I was constantly Irene I saw like a sea of red and I'm a little hurt after the counter incident. [LAUGH] So yeah, this one is retry now let's make it fail all the time. So that it this will eventually make it through its four retries, all right, you can see tries, fails.

[00:07:13]
I guess there's the initial time plus four retries, right? And logs we did cache the error. I could have it outside the pipe. I was just when I let the counsel error happen here. If I turn this to a counsel one it'd be a little clearer two, just to make it not look the same.

[00:07:33]
Yeah, you can change things. But if you miss the slash key while you're typing, doesn't do anything, right? So tries, and then we hit the cache errors situation from before.