#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.


Talk Python's Mastodon Michael Kennedy's Mastodon