Now, as a final step here,
in the getSinglePost action in the post-controller,
I wanna add a little bit of error handling here
when we create a post.
As mentioned, in the Node + MongoDB section,
way earlier in the course,
there is a problem with Express.js
related to errors caused by asynchronous operations.
Those don't reach the default error-handling middleware
out of the box,
which is a pity.
It would be better if it would work like this,
but it doesn't.
Therefore, theoretically, whenever you are working
with asynchronous code and with asynchronous operations,
you should add your own error handling
and force Express to trigger its error-handling middleware
if things go wrong.
Now, here I'll only do it
for this getSinglePost case, though,
because there I can easily show you
where our application would break otherwise.
If I do log in real quick here with a valid user
and I view a post,
that, of course, works.
But if I mess with the post id
and I add a couple of characters,
then this fails and the server crashes.
And the reason for this
is that we don't even make it to this check
where we would return a 404 page
because when we create the post here already,
we actually try to convert the id to this ObjectId thing.
And it turns out that this ObjectId constructor
throws an error if it receives an id
that does not follow the MongoDB id format
which my self-entered id doesn't.
Now, normally, when code throws an error,
the default Express error-handler would become active.
But since in the post-controller,
getSinglePost is an async function,
this actually is all wrapped into a promise,
and this overall is an asynchronous operation,
and there, unfortunately, errors
generated by or inside of such async operations
are not handled by the Express error-handling middleware.
To still ensure we reach the error-handling middleware,
we instead have to manually handle the error first
and then call next and forward the error.
So, therefore, we can use try-catch here
to try creating a post.
And for that, I'll create a variable named post
to which I'll assign a value inside of this try block.
And then I catch any errors that might be thrown
by the operation that lives in the try block,
in this case the creation of the post
where this conversion of the id will actually happen.
If that generates an error, then we can catch it here.
And then what we can do here
is we can use this third parameter
which we get in all middleware functions,
and route handlers are just middleware functions at the end,
which is this next function.
We can call next and pass the error to it,
and this will then reach
the Express default error-handling middleware,
but we have to do it manually.
I also will return this
or return thereafter, doesn't make a difference,
because I wanna ensure that this other code doesn't execute
because it wouldn't work
if we already failed to create an id.
With that, if I now save that,
if I now reload this invalid id, I get An error occurred!
If I instead wanna get my 404 page,
then I can, instead of calling next, simply manually render
this 404 page like this.
So that would be an option.
It's up to you what you wanna do if this error occurs.
So if I do that and reload, I still get An error occurred!,
because actually here I don't have a 404 page anymore.
If I quickly create a 404.ejs file, though,
and I say Not found! in here,
Could not find the resource,
then you will see,
maybe I'll also set the title to Not found!,
then you will see that if I save this,
I added this template, now if I reload, we see that.
So that's how we can then handle the error ourselves.
Again, theoretically, you should consider doing that
for all your tasks,
for all the actions where you reach out to the database,
because all those things can theoretically fail.
However, to keep that code fairly structured,
I will not do it here.
We will again see proper error handling
in the next course section, though,
which is about that main course project
where we build this online shop.
But this is a specific case you should be aware of.