- So at this point, we're pulling a movie information directly from the file system of our project, but we don't have anything saying,

hey, this movie doesn't exist. Currently, if we tried that, we would just get an error. So for example, if we jumped in here and we did another awesome movie, The Movie,

we'd get an error saying, no such file or directory, and then it would point to the path that it tried to read to. So instead of that happening, what we would prefer to do is show the user back a 404 page

or something stating that that file or the requested resource does not exist within our system. In addition to that, there's an additional step that we can do that will restrict

what exactly makes up a valid slug in terms of our route parameter. So currently, if we did something like capitalized another plus awesome plus movie,

we don't have anything in our system invalidating this particular slug, and it would attempt to read out a file at that location. So let's take care of both of those instances within our route definition in this lesson.

So let's hide our browser back away, head back into our routes, and let's first determine whether or not the movie exists. The most simple way to do this is going to be wrapping the read file within a try catch call.

So we can cut this line out, give ourselves a couple of line breaks here to give us space, do a try. Within that try, we can try to fetch the movie information.

If it fails at all, we can catch that error and do something with it. Now, the first thing you're gonna notice is our movie down here is now showing a red squiggly indicating that there's some form of an error.

The reason for this is because now a variable doesn't exist called movie within the same scope. So try here is a block level code block,

and we moved our movie declaration into said code block so it no longer exists outside of the try call. So we do have a couple of options in terms of how we can provide the movie

back into our EdgeJS page. We could do let movie right up here. We don't necessarily have a particular type as of yet that we can assign this movie,

so we'll just do type any right now, and then get rid of the const declaration and then just set movie to that variable. So now movie exists again. We can give this a save, jump back into our browser,

go back to a valid URL that we have right here, give the page a refresh for sanity's sake, and it still works, but there's an alternative approach that we could take here as well. If you remember back before,

whenever we were first learning how we can provide stateful information into EdgeJS, within the view property on our context, there's a share method. So let's go backwards a couple of steps here. So we have an option to,

instead of providing movie directly into the state of the page, we can get rid of that state, and instead we can share it within the block level declaration here.

So if we have a movie, we could do ctx view share, and now we can share that movie via this call. There is a difference between sharing information

and providing information directly into the state, but we don't need to learn about that quite yet. We can focus on that later on. So we can give this page a save, jump back into our browser and do a sanity check.

Let's switch from another awesome movie to my awesome movie, and it still works A-okay. So now that we have our movie's fetch wrapped around the try-catch, let's see what we get whenever we try to attempt

a non-exist movie. So let's do not exist, and since we have that wrapped around the try-catch, we still get our underlying page rendered out A-okay.

The only difference here is now our movie is undefined rather than having information. So instead of showing undefined now, we wanna show that that resource does not exist, and that's where the do something comes into play.

So whenever we do catch an error, whenever we attempt to read from the file, what we wanna do is provide some form of standardized exception or error

that allows us to set a status and a message to return back to the underlying page. For this, AdonisJS provides a class called exception, and we can throw that exception.

So let's throw new exception. This allows us to set a message as well as some options, which includes a code and a status number.

So we can say for our message, could not find a movie called, and then we can provide our CTX params slug within there.

For our options, the code, we can provide an E, which is short for exception or error, whichever way is easiest for you to remember, not found.

And then lastly, we can set the status to 404, which is the HTTP status code for not found. Now we can give this a save. Let's jump back into our browser,

give the page one more refresh. And now we get the error page stating that could not find a movie called, my awesome movie not exists, and the status is 404.

Awesome, so now we have our application properly handling whenever somebody tries to request a movie that doesn't exist. But what about the use case where somebody tries to provide a slug that's invalid,

at least in the eyes of our system. So let's hide our browser back away and take care of that one next. For that one, we can use a route parameter validator. That's something that we chain off of our route definition,

similarly to how we're giving the route a name. We can do this via a method called where. Within where we provide the parameter name, in our case, our parameter name slug,

and then we provide some form of a matcher. Now, Nonstjs does provide a couple of matchers automatically for us. We could do router.matchers,

and they have one for number, slug, and UUID. Well, slug happens to match exactly what we're looking for, so let's go ahead and utilize that one. And before we round this out,

you'll note that it's highlighted in purple within my system. In yours, it might be a different color, but this notes that it is a method, so we wanna call it. Cool, now, before we give this a save,

I do wanna note that we can also provide regex directly into here as well. So if you had a particular regex string that you wanted to validate to, you could provide that here too.

So something like a case insensitive regex, you could do something like A through Z, and something like that would work. I'm gonna paste the slug route matcher back in here.

And now if we try to jump back into our URL and request something like my plus awesome plus movie, give that a run. We still get back an error,

but now you'll notice that the 404 error we're getting is different. It's no longer that it can't find the movie, but now it's that it cannot find a route for the particular request.

It's stating it cannot find a get request route for the path slash movies, my awesome movie. But if we go back to a valid URL, give it refresh for sanity sake,

everything still works A-okay. So now in order for AdonisJS to use our movies slug route, our slug needs to match against our validator

for the route parameter, giving us just an extra level of safety. And it also allows us to define additional routes that are relatively similar

to slash movies slash something later on.