Let's try a different example here.
Let's say I'm creating a simple sum function.
Yes, I know it already exists in Python, but we'll just create our own.
A simple one that takes num one and num two.
And in here we'll just return num 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 error must be string not int.
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.
This part.
And here have an exit clause.
That says perhaps if we get a any type of error.
We'll print.
Something is wrong.
If I run this.
I get something is wrong.
But here's the problem.
By just doing accept 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 error is 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 error 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 error.
So I'm saying, hey, if you catch 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.
Look at that.
I get the error printed.
Let me just open this up a little bit so you can see clear.
Look at that.
It actually gives me the air that I want.
So that I can see that online.
Five.
On this line, I get a type error unsupported operant 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.
Here 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 error.
So this is sometimes tricky.
But what it means is what we get out here is actually an error 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 error.
So that now.
If I run this.
Again.
Please enter number.
Unsupported operand type s four plus int and str.
So I actually get this error available to me.
Now, if I was to just print this error, let's see what it looks like.
If I click Run.
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 num one by num two, let's just run this first.
I get oops, if I do one divided by zero and I run this.
I also get hoops 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 error 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 accept block.
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.