Now, we talked a lot about
404
errors.
That's just one kind of error that could occur, though.
It's an error caused by the user of this website
because the user entered an invalid URL.
It could also be an error introduced by us as a developer,
if we had some invalid link somewhere on our website.
But typically, it's caused by the user.
Now, there is a different kind of error,
which is not caused by the error,
and which we can't always avoid as a developer,
but which we still should be prepared to handle, at least.
And, that's a server side error.
And in this simple website,
we probably won't have too many issues,
but one thing that could fail
is reading or writing to this restaurants.json file.
Of course it typically works,
especially for testing this locally.
But theoretically, if this would be a real website
hosted on some remote machine,
then maybe if too many visitors
are visiting this page at the same time,
there might be multiple conflicting
read or write operations.
And hence, one of these operations could fail.
Now, that is actually a scenario which we can prevent
as a developer by using a proper database,
which we'll do very soon in this course.
But still, it is one possible scenario
where things can go wrong.
And in general, in web development, things can go wrong.
You should never assume that everything just works.
Now, to simulate data reading or writing fails here,
I will rename this file.
Now, that's of course not a realistic scenario,
but it allows us to test what users will see
if reading or writing does fail.
And since I renamed this now, that will fail
because I tried to read a file named restaurants.json,
whilst the file actually is named restaurant.json.
And hence, if we now, for example
go to browse restaurants, we get this error.
And that's a very ugly error,
which we don't wanna show to our users.
Instead, we again,
typically want to show a more customized error message.
Now, we could prepare a standard server side error page,
just as we have a standard 404.ejs file,
or,
we simply send back different responses if we get errors.
Now, I will go for the standardized error page here,
because we'll dive into more specific,
customized error handling later.
Now, to have a standardized page,
which can often be very useful,
I'll add a 500
.ejs file here.
Five-hundred is the standard error code
for server side errors.
A 500 status code
means that something went wrong on the server.
Now, here I'll copy that 404.ejs content and paste that in.
And then, I'll just say, "Something went wrong!"
And here, we could now add some extra explanation
where we said,
"Unfortunately, something went wrong on the server -
we're...
doing
our best...
to fix it
as quickly
as possible!"
Something like that.
Now, I wanna send back that page,
that template here,
whenever something does go wrong on the server.
And how could we achieve this now?
Now, there are different ways of achieving this
as always in development,
but it's such a standard scenario
that something goes wrong in one of your routes
that Express actually has built-in support for that,
and makes it very easy for you to handle such errors.
We can, again, work with our own middleware,
just not with a standard middleware,
like we have it here for the 404 page.
But instead, a middleware that will only execute
if an error occurred on your server.
Because that's what's happening here,
and Express will detect this.
And then, if you added your own error handling middleware,
Express will call,
will execute that middleware for you.
For this, we can add another app.use method call here,
and pass a function to app.use.
But this function now works a bit differently,
because this function
will now not just receive request and response,
but instead four parameters,
and it must receive four parameters,
because that signals to Express
that this is this special default
error handler middleware function
that should be invoked by Express
if some error occurs anywhere in your Express application.
And the four parameters which you should accept here,
is an error object.
Then, request and response as we have it here.
And then, a fourth parameter, which is called next.
Now, this error object is generated
and populated automatically by Express.
So, by that third-party library.
And it simply contains more information
about the error that occurred.
You could use that extra information
to handle different errors in different ways.
For the moment, we won't use it,
but we need to accept all four parameters here.
So, we need to write this function like this
for Express to understand
that this is this special error handling function.
Next is actually a parameter which you could accept
in all your routes and the standard middleware here as well.
But we haven't done this up to this point
because it's a bit more advanced and hard to explain
if you don't have a use case for it yet,
which we don't have at this point.
But we'll see next later in the course again.
In the end, next allows you to have multiple middlewares
that will work together.
And when you call next inside of a middleware,
it allows the request to move on
to the next middleware or route handler in line.
But we'll see it later.
For the moment, we just need to accept it.
And then, here we can render this "500" template
that we prepared.
And with that, if you save everything
and we added this default error handler,
if you now reload this page,
which crashes at the moment,
you get this standard 500 page.
And that's huge,
because now,
to your end user,
your site doesn't crash.
Sure, something went wrong,
but we are still on our page
and we can still generally use it,
and just parts of the page are not working.
And that is something we typically wanna do.
We wanna provide a good user experience
and if something goes wrong,
we at least wanna handle it
with a custom page and message.
Of course here,
the entire scenario was simulated,
because, of course,
you typically don't rename files that you shouldn't rename,
but it allowed me to show you
this server side error scenario,
and how you can handle that.
And that is also something we'll encounter later again,
when we dive into bigger course projects again,
when we build our online shop later,
because there,
we of course all do wanna handle cases
where things go wrong.
And hence, I'll bring back the "S" here,
but I'll keep that server side error handling in place.
Now, of course everything works again, though.