 Hey everybody, this is Brian and welcome to the 10th Python tutorial. Man, we are just hauling through these, collect Python 10. And what I want to cover today is exemption handling or error handling. Obviously, you've seen me make a few mistakes and I'm sure as you've been following along you've made a few mistakes. So how do you handle those mistakes? Well, we use what's called the KISS method, which is keep it simple and stupid. Or simple slash stupid. And what does that really mean? It means don't complicate your life any harder than it has to be. So we're just going to say def do something and let's say we're going to n equals 0, x equals 5, y equal, let's just get creative here, x divided by n, print the value of y. You know, just something generic here. And then we're going to totally forgot our little brackets that always bites me for some reason. Just so we can see that we're starting the program and then we're going to do something. And let's run this and see what happens here. Oh no, we have an error. Shocker, we're dividing by 0. Well, this is a standard error message in Python and I'm sure you've seen these before. And this is called the trace back. And what it does is it starts where the error originated. So like if we just go line numbers, line 13 in module, which means in the current module, if it was a different module, it would give you this module name would be different. All right, so line 13 do something. So we know instantly it's coming from do something. But it goes a step further and says line 9 in do something. And it gives you the actual code that's calling the error line 9, this guy right here. And it gives you a description, zero division error, division by zero. If you've taken any sort of rudimentary math class, you know, you cannot divide by zero. I'm horrible with math and even I know you can't divide by zero. It's just not possible. You can't do it. All right, so how do we get around this? Like let's actually say number and let's give the user the ability to enter the number. Right, so we're going to run this. What do we do again? Oh, yeah, dirt. All right, so we get 1.1. We can change this. So we know our function is actually working, 2.5. So we're going to take whatever divided by whatever. Now if the user enters zero or back to square one, we're going to have that same error again. We don't want that. So we need some sort of exemption handling and it's in the form of a try exempt finally. And we're going to explain that. Say try and we're going to indent this code. Notice how it gives you a little squiggly when you use a try. It's expecting an exempt or a finally. The first thing we're going to do is exempt or accept, sorry. And we're just going to accept exemption as E. And this is what's called a catch all. Let's make that a little prettier. Something went boom. Now what try and accept does is it'll try this code. And if something bad happens like a division by a zero, it'll run this code because this is a catch all. This will catch any exception out there. So let's run this. And you see now it says something went boom, division by zero. So we have a nice pretty, you know, something happened. And E is actually an object. So you can actually get into the args, you can do the trace back, you can do pretty much whatever you want. You can get the actual base memory on that. So it makes it a lot easier to work with. And notice how it didn't kill your program. Even though there was an error, your program keeps juggling along happily because you encapsulated it within a try and accept. So that's one way of doing that. Now a finally is a little bit different. Finally will always execute regardless of what happens up here. Notice how why never prints because we had a division by zero error. But if we run this, you'll see finally I get to run. So even though there was an error, finally will run. And you don't necessarily need this code. You can just do a finally. You can do try finally. You would do this for the example if you had a file or database or some resource. You would open it and then when you're done in the finally block, you would actually close that resource regardless of whether or not you had an error. Now as you might have guessed, if you're with, you know, been working with other languages, you can actually classify exemptions. So we'll say zero division error. We'll say we please do not divide by zero. Let's get rid of that. Now when we run this, notice how it says please do not div by zero instead of the catch all because we've actually specified we want to catch zero division errors and do this block. General rule of thumb catch all are bad. You want to know what sort of problems are rising in your application. Another thing you should never do is simply pass. For example, runtime error and we'll just say pass. If we've never covered pass before, what pass does is it just does nothing. It just takes the execution context and jumps right out. That'll create what's called a silent error. Actually it'd be a better example if I had just done it in the division by zero. Let's throw a pass in there. That's what some people do. They'll say if you divide by zero, just pass. That creates what's called a silent error. You never knew that happened. You never, never, never, never want to do that. Repeat after me, never do that. Reason why is because you want to know that error occurred. You want to do something with that error. You want to either log it or correct the problem. You know, for example, please do not div by zero. You're telling the user, hey, choose a value greater than zero. One thing you should really understand about error handling is that you don't want to go completely crazy. As you can see, the error handling actually is bigger than the algorithm that we wrote. That's called defensive programming and it's good to do that. But you don't want to make an exemption for every single type of runtime error that's possible and there's a lot of them. So if we go out here, I was wondering what was that? Ow. Stocks, never mind. If you go out here, you can see that there are a bunch of exceptions. And you don't want to make one for each and every one of these. For example, you don't want an OS error in that algorithm we just wrote because we're not dealing with the operating system. You don't want a stop iteration error because we're not dealing with it. So you kind of got to look at your code and say, what really is going to happen here? Well, division by zero is completely possible. But I would always, as a rule of thumb, put the catch all in here because if you don't and something else happens, you're going to get a runtime error. For example, let's do this. Let's just comment this out. And let's actually do, let's say we just expect a runtime error. And we're going to say print. This may not be the best example. Actually, it's not. Let's do OS error. There we go. Now let's run this. You can see how now our program crashes because we never captured that division by zero, either this way or with our catch all. So you're going to want, at a bare minimum, a catch all statement. Something went boom, division by zero. But it's always better to know what kind of errors you're getting into. That way you can handle them appropriately. That was a mouthful. It's been a long day. Thank you for watching. Please feel free to visit my website for the source code for this and other tutorials. Just go to Python and I'll upload. I just did a bunch of videos. I think I did like four or five videos right in a row. So I'll upload all those before I go to bed tonight. Hey kitty, daddy's recording. Yes, I know. You're hungry. Visit Facebook and join the Void Realms Facebook group. There's 200 of us out there that are eager to help. And if you do join, be sure to offer help whenever you can. Nobody's an expert in any one thing, but if you have information and somebody's asking for help, just jump in there and leave a quick comment.