Okay, so I think that we can just finish the whole problem of error handling in this video.
We are missing just one piece, which is rendering an error page.
If something really bad happens and we are running in the context of a web server.
Why won't we do it right now?
This means we need to add this render error page method.
And what I'm going to do is I will copy the render CLI error.
The reason is this will be very similar.
We just have some slight differences.
So the name should be Render error page.
Let me change that right here.
So we also need to know if we are in the debug mode.
This would be very useful on the web because this is where other people are seeing our project and our
website.
So it's crucial not to reveal some insights that should not really be shown to anyone.
And in here we are going to simplify the error message a bit.
Also removing all the colors.
This doesn't make sense on the web.
This would be our error message.
And also in case of debug mode being disabled we don't need any colors.
Okay, so essentially I think the top of this method can be exactly like this.
The things that are different is how do we present this message, this error message.
So the error codes don't make any sense on the web.
This is only for command line programs.
And now obviously this block needs to be removed as well.
For now let's just simply return a response code.
Unhandled Exception means that something terribly bad has happened.
Otherwise we would have handled an expected error.
That's why we return the 500 code.
Then we're just going to echo the response.
And we're going to use the view class render method.
And we are going to render a template that we're going to prepare.
Let's call it just 500.
Does it have any data.
Well yes we do have some data.
First the error message this is our error message then the trace.
And finally whether we are in the debug mode or not.
Okay.
We need a semicolon in here.
And Optionally, we can supply a layout.
Maybe we can do that.
This would be layouts main.
So now we need to add a view.
So in this views folder in the app directory let's make a new one.
So I think we've called that errors.
And in here we are going to add a view for every possible type of error.
For now we are only handling the 500.
Let it be just this for now.
So let me add the header saying oops, something went wrong.
Then let's add a paragraph outputting the error message.
Escaping it using HTML special chars.
So here we have access to a variable.
So remember how templates work.
Everything we are passing through the data array is becoming a variable in the template.
And next up we can check for the debug mode using is debug and alternative template syntax.
So this is an H2 element where we are going to display the stack trace.
Then use the pre element to have some basic formatting and also escape stuff using HTML special chars.
The trace is a string so we can directly output it.
And the if statement needs to be closed with an endif.
Now finally, let's give our users a chance to recover.
So to go someplace where things should potentially work, we would not like to leave the users hanging
without knowing what they should do next.
That's why I think we should give them a link, maybe to the main page, and just say that they should
try and return to the home page.
All right.
I think we don't need to do anything else.
And now we should just make sure that this works.
I think we should jump to the home page.
And again, inside the index action, we should just throw a new exception.
So we are triggering those errors so we can see if the error handling works.
So this has happened on the web.
Now that's important as we need to check if our error handler properly displays a page.
If the error happens on the web and that it reports this error to the error log in all cases.
Now we should start a server.
So this is php s localhost.
Let me use port 8000 because I know it's not taken.
And let's start it in the public directory.
And in a second we're going to see how does it look like.
So it seems that the error page is rendered almost properly.
The exception is that we seem to have wrong format for the message.
Not all the info is displayed, but you can see the title, the page and the stacktrace.
So everything started with router dispatch.
Then we had call action with all the parameters and the error has happened inside home controller index.
So that is a stack trace.
That's super useful info.
If you need to debug the problems and see what was the flow of the program.
So now let's take a look at the problem.
So I think that we might be missing one of the.
Yes.
So we should start with the date.
And I think that we are just missing one of those placeholders.
We should have five, not four.
And after this small change, when I refresh I should see the date and where this happened and on which
line, which is exactly what has happened.
Now let's also take a look at the error log.
And obviously we've got everything logged.
So this worked perfectly.
So now that we have most of our framework built and the generic code is almost done, we might have
to do some tiny changes or add something here or there.
But I think we should now focus on doing the fun stuff.
Building our blog application with a dashboard.