Welcome back, everyone, to this lecture where we're going to be discussing responses and for, of
course.
So inevitably, there's going to be a time when a client requests a Web page view that doesn't actually
exist, or they accidentally provided the incorrect URL route that didn't match up with what you were
expecting on your end of things.
In these cases, you can try to preempt an error page by using a dispute response not found to still
return some web page for the user and at least inform them that you weren't able to find what they were
looking for.
Django also has a default for a four page that we can display in case we get a 404 error.
So later on, we're going to have a lot deeper into templates and see how to create our own custom 404
page.
But for right now, I'll just focus on two main functions, which is HTP response not found.
And then the HDP 404 response.
Let's head back to our code editor.
All right.
Here I am back at the website we've been working with.
Recall that we had this dictionary of articles and then a news view that ended up showing you the particular
page for whatever topic was asked for.
And then we had this kind of silly ad view here.
I'm going to collapse this one since we won't be working with it right now.
And then here in URLs that pie, we ended up using that topic and displayed that particular news view
from the articles dictionary.
But right now, if we go to our website and say something like first app for sports, we get the sports
page.
But then if I ask for something that's not there like arts, then I get a key error.
Well, it'd be nice if I could try to preempt this sort of error and just tell the user, Hey, I can't
find anything for this particular topic.
How do we actually do that?
Well, we'll come back to our view and we're going to use a try except statement.
So what we're going to do is we are going to inside of news view.
We're first going to attempt to try make sure our indentations correct here.
We're going to try to figure out that particular headline or page.
So I can say result is equal to.
And then I'm going to say here articles.
Topic past.
So I'm going to try to get that result and then we're going to return, and here we're going to grab
your response article's topic, so we're going to try to do what we just did before.
Now, in the case that we can't find something like arts, that's where we have to have some sort of
exception where we can use the h to the poor response not found.
So what I'm going to do then, is if that fails, I can say, except.
And if the accept line or block is already running, then I know we don't have that topic.
So I could just say result is equal to.
Let's say no page.
For that topic.
And then inside of this block, I'm going to have and then sit here, return, and here I can say HTP
response.
And I say it should be a response.
Not found, and in order to use this, you have to make sure to import it.
So at the top here, I've already imported from response HTP response not found.
This is essentially a further indication that, hey, what you're looking for, I don't actually have
a web page for that.
And then we can still pass in results here, and we're going to save that.
And so now what happens is we come back here and I refresh this.
I say, hey, no page for that topic, but what's nice about this is instead of just doing a normal
HTP response, I'm actually taken to account of the fact that this is technically if we look down at
our terminal a 404 error, meaning there was no page for that particular URL route.
Now I should point out, if you check out the documentation, there are two main pages I want you to
be aware of.
One is the documentation on writing views, so it's just the general topic on writing views.
It talks about a simple view stuff that we've already talked about, but it also has a section on returning
errors.
So the main one that you start off with is HTP response not found.
However, as you continue developing your website would be nice is to switch this out for some sort
of generic 404 exception.
Otherwise, you'd have to keep automatically defining somehow the specific errors you want for every
single view.
Instead, it would be nice if you could just write HTP four or four and then say something like, Hey,
this page doesn't exist or connect it to some 404 template you have later on.
I should also note that there are many subclasses that are not just HTP response and HTP response not
found.
You can check that out on a link here on this page, where it talks about the URL dispatcher, as well
as the requests and views.
There's a request and response objects page that basically has a list of all the different types of
subclasses inside of HTP response and how it works.
So a lot of what we work with here is on this page.
It's a really long page talks about kind of all the different subclasses of HIV response, all different
methods on that.
So you can see here a severe response subclasses.
There's redirects not modified, but requests a step response gone.
So essentially, all those 404 HTML codes in general, four or three for over 400, 500, etc. the main
ones all have subclasses associated with them.
However, really, what we're looking for is an HTP response not found to be replaced by just raising
some sort of generic for a for code that later on, when we learned about templates, we can actually
connect to a specific 404 page.
So how do we do this?
We're going to come back to our code and we're going to do two things here.
Instead of saying accept return response, not found.
I'm going to raise the HP 404 error and say four or four generic error.
And then later on, when we actually learn about templates, we're going to end up doing is this will
actually be connected to something like our custom 404 HTML template that we can connect to later on.
Right now, though, we can actually just raise it as a simple string in order to use each TDP for a
form when you come back up here and import it.
So we have HTP for four.
And let's make sure that's correct there.
All right, so that should be looking good, that's matching up here with the import.
One thing to note, though, is you actually need to adjust your settings, otherwise you'll still get
some sort of debug page.
So even if we save these changes.
Let me show you what happens before we edit the actual settings file.
So I come back to my website here, and if I refresh, I see Page not found for 04 and it says 404 and
then the term actually put here.
Generic error.
If you scroll down here, you'll notice that it says, Hey, you're seeing this particular error page
because you have debug equal to true in your jingo settings file.
Change that to false and jingo will display a standard for a four page.
So let's experiment a little bit with this.
Later on, we'll talk a lot more about project settings, but right now I do want to talk a little bit
about this.
And there's two things here at the change here.
One is our debug settings and the other is our actual allowed hosts list.
Somebody keep in mind, though.
Whenever you're developing a Django project, you do typically want to have debug equal to true that
we can help debug what's happening with the moral force and to see if it's working.
As you expected, when you deploy a website, you definitely want to have debug equals to false.
Otherwise, your users will get some sort of page like this, which gives way too much information about
the website operations to the public.
So we're going to come back to our Visual Studio code.
Go to settings that pie.
And let's actually kill the websites we're going to control, seeing my terminal to not have the website
run anymore.
And we're going to say debug is equal to false and again, security warning don't run debug turn on
in production because there's a debug editing tool and it gives way too much power to any person visiting
your website.
The other thing is, when you have debug equal to false, you need to actually tell Django which hosts
are allowed.
Now, because I'm running this locally, I'm simply going to say the following host is allowed.
It's the one two seven zero zero one that we've been running off of.
So remember, we're running off of this right here, so I'm going to say that's an allowed host.
Save that change.
Let's run our site again.
OK, so the site is now running.
I'm going to come back here and let's refresh the arts page and we see we get not found.
The requested resource was not found on the server.
So that is essentially Django's 404 page that a user would see.
How do we deploy this in real life with debugging turned off?
OK.
So what I'm going to do is turn back here to debug.
Set that equal to true again for the rest of these lectures, and we can delete this allowed hosts.
That's not necessary anymore.
Go ahead and save that.
We'll talk a lot more about settings in general later on, but let's do a quick review of everything
we covered in this particular lecture so you can always use a try except statement in order to take
into account the fact that a client may visit something that doesn't actually exist in the beginning.
You may just want to use it to response not found, especially if you're debugging things later on.
Which you're going to want to do is use some sort of generic HTP for.
And later on, we'll link it to our own custom forum for each HTML template.
All right.
That's it for this lecture.
I'll see you at the next one.