Let's try a different example here.
Let's say I'm creating a simple some function.
Yes, I know it already exists in Python, but we'll just create our own, a simple one that takes number
one and number two.
And in here, we'll just return number one plus NUM two.
Now, if we were to just simply do some one.
And some, too, and I ran our program.
Well, let's print it out first.
I click, run, I get one and two because it just adds the two strings together.
So let's just do this and click run.
I get a type air must be stirring not and so based on what we learned, how do we handle this?
Well, we can add a tri block in here and wrap this function or we can build it directly into our function.
So I can say try.
And here have an asset class.
That says perhaps if we get a any type of air.
Something is wrong.
If I run this.
I get something is wrong.
But here's the problem, by just doing, except with no exceptions, as a programmer, I'm reading this
and I don't really know what actually went wrong because it could be so many things.
So a good practice is to always catch these errors based on a specific exception this way, you know
what the areas and you can be more descriptive.
So here we can say type error and this type error, we can just say, please enter numbers.
So that if I run this again, please enter numbers.
So now, all right, my error is more descriptive.
I should fix this and make sure that I enter numbers.
Awesome.
Now, a common pattern when doing hair handling is to do something like this type error as and then
doing something like a variable.
So whatever variable we want in our case, let's just say er so I'm saying, hey, if you can type error,
let us use error in our error message so I can say here.
Plus, air.
So that if I run and let's do a string here, if I run.
I get the air printed, let me just open this up a little bit so you can see a clear.
Look at that, it actually gives me the air that I want.
So that I can see that on line five.
On this line, I get a type error, unsupported operand, and I get a descriptive error of what is happening,
so maybe I could use it in my output message.
But what if I don't want to use this and I do run?
All right, everything is working again if I do, plus.
Er and I click run.
And this is actually tricky, but it says here, during handling of the above exception, which I'm
doing, another exception occurred, oh boy, I try to handle something and I had an error within that.
Er, so this is sometimes tricky, but what it means is what we get out here is actually an air object.
It's a built in exception in Python.
You can't add in here the way I have.
Instead we want to use an F string so I do F and then here pass it the air.
So that now.
If I run this.
Again, please enter no unsupported operand types for plus ant and SDR.
So I actually get this air available to me.
Now, if I was to just print this, er, let's see what it looks like.
You see, this is the part of the air that we get, so it's very, very useful if you want to give meaningful
errors to your users.
Another interesting thing you can do is something like this, where you wrap these errors together,
so let's say we have zero division error as well.
And here, we'll just say, oops, if we, for example, divide number one by number two, let's just
run this first I get oops if I do one divided by zero and I run this.
I also get oops, so I can handle multiple errors the same way.
I can also say as air here and just actually print out the air and if I run this.
I'll get division by zero, or if I do a string.
And run this, I get the other air type, so this, again, is really useful to combine different errors
if you want to handle them the same way.
But what if we actually want to raise our own errors?
That is, we want to throw our own errors maybe inside of this except luck.
I actually want the error to display for certain types of errors.
How could we do that?
Let's find out in the next video.