Error Handling Q&A

[00:00:00]
>> I would like to just open the floor for any questions that anybody may have over what we've covered over the last couple modules,. I realized that we are kind of coming from we're taking some really high level stuff and trying to distill it into kind of very simple terminology.

[00:00:22]
And I wanna make sure that one that is connected at the same time that I haven't skipped over something that might be relevant. Or important for any of our audience members or anybody who is watching this live workshop. So I wanted to before I go any further, just open the floor up for questions or comments about anything that I've covered up to this point.

[00:00:54]
I've seen that you didn't catching the error in the service? Where do you think is the best place to catch the error? You see when you in the effect catch the air it's so the question is, or the observation that I did not catch the air in the server.

[00:01:15]
And the question is where is the best place to do that? And so, that is a really good question. And the answer is, it really depends on the context. So let me give you a couple things to consider as you kind of ponder this. I believe when possible, you want to capture the air at the point of origin.

[00:01:50]
So as soon as possible, and ideally, you want to try to recover. At the point of origin, now, occasionally, it depends on the type of the air that you're not able to recover or it's actually the result of. Like a user error so for instance, you're filling out an order form and somebody mistyped their credit card.

[00:02:18]
Well, there's no way to recover from bad information. And so that will cause an error. You're not able to recover from it as well as you need to surface this back up to. Not where the air happened, but really the point or the catalyst of that, which in this case is the user.

[00:02:39]
And so that's kind of the consideration there is. What is the nature of the air and does it require human intervention? From that point, then the user experience comes into play. And you have to ask yourself, even though I'm able to recover it here, is it affecting the user experience and do I need to fix it?

[00:03:04]
So typically, you don't turn into like this hybrid approach of You might capture the air at the server. So let's say it's like it's an authentication error that somebody tries to access and they're not able to do that. Well, you capture that at the point of origin, which would be at the server.

[00:03:22]
But then you need to as well handle it in your front end application. So in the context of an Angular application using NGR x, I would handle that in the effects layer. So effects are very, very good for any kind of flow control, to where I think everything else within mgrs is pretty straightforward.

[00:03:47]
Where I think people really have a tough time within GRS is around this asynchronous control flow, because it's a synchronous. And but that's where one I think your asynchronous control flow logic should go, as well as. Your business logic because effects give you this really nice way to compose individual pieces of logic and then just kind of string them together via events.

[00:04:15]
So that was a very high level kind of architectural dissertation on where do you handle errors. What kind of depends, and it depends on what you need to do about it as well as. Handling an air and surfacing an air are slightly different, cuz you may wanna handle an air at the metal if you will.

[00:04:33]
But you have to be really careful what you surface to the user. You may not want to expose, do it like it's a stack trace and just throw it out into the browser. That would be very bad depending on where you are currently working or where that app is deployed?

[00:04:49]
So hopefully that made sense