Dynamic routes are
an extremely important feature,
which you will also see again and again
throughout of this course,
but also in any website you're going to build.
Now, what happens though, in this dynamic route,
if we try to get a restaurant
with an ID that doesn't exists?
So what happens if I manually change this ID
here in the URL to R100, which is not a valid ID,
I mean, it's maybe a valid ID,
but it doesn't exist in our data set.
If I hit enter here,
then you'll note that this keeps on spinning.
So we don't load a page and eventually
this will time out and crash.
Now, why does that happen?
Why will we eventually time out here?
Well, we will time out because in this route,
which handles this request, we only send back a response
if we did find a restaurant by that ID.
Otherwise we don't send back a response.
And I mentioned earlier in the course already
that if you have a route
where you don't send back a response,
ultimately it will time out
and the browser will show an error eventually,
because it never receives a response from the server.
And your server should always send back a response
even if it's just an error response
that tells the browser that something went wrong.
But everything is better than just timing out
and not knowing what's going on
as it's currently the case here.
We don't wanna wait until this eventually times out.
No user will stick around that long.
So therefore here, we also wanna send back a response
if we don't find a restaurant.
And how could we make that happen now?
Well, you could think that you may be at
a else case here in this if block
and you send back a different response
if you make it in here.
But this would be wrong, and why would that be wrong?
Well, keep in mind that this if statement
is evaluated for every restaurant
in this storedRestaurants array,
and we won't have a matching condition here
for the vast majority of all restaurants.
There will only be one restaurant at most
that matches with its ID
because we'll never have more than one restaurant
with that ID we're looking for,
and in some cases we'll have no restaurant at all.
So if we return an error response
whenever this condition is not met,
then we have a lot of cases
where we don't meet the condition.
And we might not even reach the restaurant
where the condition might've been met.
So else is not a good solution here
because we might send back an error too early.
Now, therefore the proper way of handling this
is to wait until we exhausted our list of restaurants
and we went through this entire list of restaurants.
So after this for-loop.
At this point, we had a look at every restaurant
and we compared all the IDs.
And we now know that there is no restaurant
with a matching ID.
And therefore now is the time to send back an error response
where we let the user know that we didn't have a match.
Now, how should this error response look like?
That is up to you.
You could send back this restaurant-detail template,
maybe with some alternative content.
In this restaurant-detail template,
we could also add a if check
and then maybe check if we have any restaurant data,
in which case we output that.
And if we don't have any data, we output something else.
That could be one option.
An alternative would be to prepare
a dedicated 404 error page.
And we have all seen these kinds of pages
where you visit some part of a website
and all of a sudden you get this 404 error page
that tells you that this resource couldn't be found.
And I wanna indeed add such a page.
So I'll add a brand new template, 404.ejs.
And in there I'll grab the general skeleton
from about.ejs let's say.
So I'll copy that and parse that in here.
But then here in this h1 tag on the 404.ejs page
on this template, I'll say page not found.
And then maybe we add some explanatory text below
that where we say, unfortunately we weren't able to,
whoops, we weren't able to find this page.
And of course you could add
a more detailed error message here,
but I'll keep it fairly simple deliberately here.
So now that's my 404 error page, which I wanna show
if we don't find a restaurant.
And to make that work, back in app.js
after this for-loop as discussed,
we can now again render a response,
but now it's the 404.ejs file.
And we don't need to parse any data into that
because this template, in my case here at least,
doesn't use any dynamic data.
We also don't need to return here
because previously I returned to force a stop
of this function execution.
Now, here we are at the end of the function anyways,
there is no code after that, so we could return,
but it really doesn't make a difference.
The function execution stops after this line anyways,
because this function in which we are here is done.
And hence this is enough.
And now with that, if you save this,
if you reload this unknown ID,
you now get this 404 content,
which is better than timing out,
and which clearly informs the user
that something went wrong.