00:00 So we've got our error boundary set up, and one thing that we didn't mention was we have in our username right here, we've got this invariant response. Remember we put that there, and what this invariant response does is throw a response object. Thrown response objects will also get passed to our error boundary.

00:19 So here we're saying if there's a user, then things are good. If there's not, then send a user not found body in a response with the status of 404. So if I say not found, then we're gonna get, oh no, something went wrong, sorry about that, and we can look at the error that was logged,

00:36 and it is a special object called an error response that has a status, and it has data. So we could actually put in JSON data right here if we wanted to, and that would appear in our data, and then also the status of a 404. So all of the stuff that you would expect,

00:54 which is pretty cool, actually. And so we can, based on this, this is what I call a expected error. So like throwing errors, you know, cannot read property of undefined or whatever, that would be an unexpected error, something you can't really anticipate. And so in those cases, yeah, showing this type of a warning, that's all you can do.

01:14 But for things where you expect them to happen, so like a user going to a username that doesn't exist, yeah, we can pretty much anticipate that, and we are with this invariant response. We can actually handle that better. Based on the status of 404, if it's an error response, then we can give them some more useful information like that user doesn't exist.

01:34 So that's what I want you to do in this exercise. I want you to leverage that information and display a more helpful and useful error message for the user. You can base this off of the response that you get, and you also have access to the params as well.

01:51 So give that a shot, and we'll see you when you're done.