#100DaysOfCode in Python Transcripts
Chapter: Appendix: Python language concepts
Lecture: Concept: Error handling
Login or
purchase this course
to watch this video and the rest of the course contents.
0:01
The primary way error handling is done in Python is exceptions. Exceptions interrupt the regular flow, execution of your methods and your code,
0:09
and unwind and stop executing a code until they find what's called an except clause, that is the explicit error handling that you've written,
0:17
or if they never find one, your application just crashes. That's not amazing, so let's talk about error handling.
0:23
Here we have three methods on the screen, method one, two and three, and maybe there are potentially error-prone, something can go wrong,
0:30
maybe work with the file system, a web service, a database, things that are not always well known or can't rely on them always working.
0:37
It could even just be that someone's input incorrect data and there is going to be a problem there as well.
0:42
So if we want to make sure that when we run these bits of code, we can catch and handle those errors,
0:46
we have to put this into what's called a "try...except" block. So we put a "try:", we indent the code, so it is part of the try block,
0:53
then we add the error handling the except block and it could just be except: an empty catch-all, which is not really recommended.
1:01
In this case, we are going to catch a particular type of exception, one of the most based types that we'll catch many of the errors
1:08
that we might not expect, so we'll just say "Exception as x". We say as x then we can get a hold of the actual object that is the exception
1:15
and ask it what went wrong. So, look at the error message, if this is a custom database error, maybe it has the record id that caused the problem,
1:23
or something like that, who knows. It depends on the type of exception that you get.
1:27
So here is a general one, but we're only handling errors in a general way,
1:31
we can't handle say database exceptions differently than web service exceptions, so we can have multiple except blocks with multiple exception types,
1:41
and Python will find the most specific one, so if we want to make sure that we can catch when we have a connection error,
1:47
trying to talk to a web service or something on the network, and it won't connect,
1:52
we might want to handle that differently than say the users typed in something incorrect.
1:57
So we would add another except clause with the more specific type. The order of these except blocks is really important, the way it works,
2:04
is Python will try to run the code, if an exception comes up, it will just go through
2:08
and ask does this exception object derived from the first thing it finds, and the next, and the next, and if the first one answers yes to,
2:15
it will just stop and that's the error handling at run. So if we switch these, almost everything including connection error derives from exception,
2:23
so it would run the code, throw the exception and ask, hey, does this exception derive from exception,
2:30
yes, boom handle the general error and it will never make it to the connection error so it has to go from most specific error handling to least
2:37
or most general error handling.