#100DaysOfCode in Python Transcripts
Chapter: Days 25-27: Error handling
Lecture: Demo: Error types
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
So we've stopped the errors from crashing our program but we can't do anything meaningful, we can only say, you know, that didn't work, sorry.
0:09
Let's be a little more prescriptive here. So up the top, we need to work with the various exception types, so we have to import some stuff.
0:17
So we'll say request.exceptions down here. Now in this area, we want to catch the different types of problems that can occur,
0:26
and the way we do that is we say except: and then we say 'different types', remember when we looked at that trace back,
0:32
the first thing is the category, or the type of error, and the second part after the colon was the description, just more details.
0:39
So what we need to do is, we could have potentially multiple ones of these, we'll say this, we'll say, request.exceptions.connectionerror, okay?
0:49
We be able to just go like this, and just do a little print here and say, so maybe we'll say something like,
0:56
'couldn't find the server, check your network connection', make this really obvious like that, and print that out here.
1:03
Now, it could be if this was like a web browser they could've typed it in wrong, but we've hard-coded the URL, we know that that's correct,
1:10
so if they can't connect it's not the server doesn't exist, it's really that there's some problem getting to this one known server.
1:17
So let's try this again with my internet off. We'll come down here and search for test. 'Could not find server, check your internet connection.'
1:27
Oh, how cool, that's way more helpful, we know exactly what went wrong when we want to handle that problem here.
1:34
Now the network is back and we have another problem. If we enter no search term it's going to freak out and throw what's called a ValueError, and say,
1:42
'hey that didn't work.' But all we get is, oh, that didn't work. So we could do a little bit better here, we could say, put this core exception here,
1:52
and we could put some details like so. This is kind of going to be our fallback, we don't really know what's going on, so we're going to try this.
1:59
Let's try again. Oh, that didn't work, 'you must specify a search term', and if you're just debugging it to try to figure out
2:06
what's going on here you'd say, what is the actual thing that I'm getting here? What is this actual error? It's a ValueError. Okay.
2:14
So now let's go add an except clause for that. Now notice this is gray because we're not using it, and when we're not, we can just leave it off like,
2:25
as we did with the request here. So we don't need any details, so now, try to run this with nothing, 'error, you must specify a search term.'
2:32
Now we can really tell the user what's going on. We have a few more errors that we could potentially deal with, I wouldn't leave this here like that,
2:44
and these other errors are just kind of random stuff that I threw in there to make the program crash. One is a StopIteration,
2:50
and the other is the one that you saw at the opening, which is a TypeError I believe. So we'll just let those fall through here
2:55
because there's not anything we can particularly do, they're just sort of random noise in the system to make sure you get some interesting crashes.
3:02
These have real fixes, so we have a special message for them. The final important thing to see here in this whole try except block,
3:11
is the order in which we specify the errors. If we change this around and we put this up here at the front, PyCharm's probably going to freak out
3:19
and say, "no no no, you'll never be getting to these." If we have something general, and this is a derivative of exception, this is not going to work.
3:29
It's actually just going to stop. The way it works is, it runs,
3:32
if there's an error it just looks, goes, 'is the error this type, is the error this type, is the error that type?' And, if it comes along here,
3:38
this is going to catch almost everything, and so, even though we have this, you'll see if I run it and I hit enter, that didn't work.
3:45
I mean, we still did sort of print this out, but it's not letting us get to the part where we expect it. So it's super important that this goes
3:53
from most specific to most general. So, here we have it; we've figured out what types of errors our program might throw,
4:01
and then we can handle them independently based on the type.