- Hello, welcome back to Python Fundamentals.

This is Module six, Coding Errors.

So we're gonna learn in this module what errors look
like when we make them in Python.
You may have made some already
in the past modules that we've done coding in.
I make errors all the time.
Everybody does.
They're very common.
Some are easier to fix than others.
So we're gonna talk about what kind
of errors you might encounter
and I'll give you some skills on how to fix them.
We'll also be looking at errors
in the all the future modules as well.
So hopefully you'll get the skillset to learn how
to debug your programs.
So debugging is a word we use in coding.
Bugs are the errors that are created in the code
and debugging is finding them and fixing them in the code.
So let's get started.
Let's take a look at what kind of errors come up in coding.
So in coding there are two types
of errors and we're gonna create both in today's module.
The first one is syntax errors.
Those are the ones that are easiest to fix
because they're a violation of the rules of Python
and the Jupyter Labs, Jupyter Notebook will tell us
in the output that we've caused an error.
Sometimes the output we'll get
in Jupyter Notebooks will be helpful to fix the error
and sometimes it's not so helpful.
But we will see what we can do
with the output from those syntax errors.
The second kind of error is a semantic error.
Those are harder to fix because there are errors
in programming logic and we'll do a couple
of those to see how that works out as well.
So why don't you bring up Anaconda
and we'll create a brand new Jupyter notebook.
We can create some errors
in the Jupyter notebook and see how we can debug them.
Okay, so I'm gonna go into my Jupyter Notebook
and I'm gonna create a new notebook
like we've done in the past.
I'm gonna go under file, rename notebook.
I'm gonna call this one Module Six.
The reason I don't have a Module Five is,
as you recall, we did the code together.
Module Four has the code together for Modules Four and Five.
So now I'm in Module Six, I have a brand new notebook open.
Let's go ahead and and create some variables
that we could use to create errors with, right?
So I'm gonna create a variable x, I'm gonna put 10 in it
and a variable y, I'm gonna put three and y,
so I'm not creating any errors yet
but I've created two variables, x and y.
And you can see here that you are allowed
to do multiple lines of code in the same code block.
So I have two lines of code in block one.
Perfectly legal, I didn't,
when I ran this code, there was no output, right?
So there's no output here.
That's because I had no errors
and the code I wrote didn't indicate
to Python to produce any output.
So all is good so far with our code of x and y.
Now I want to go back to a statement
that we learned in an earlier module, which is print.
So if you recall we did print Hello World.
So print can be used to print out a string in Python.
So a string is in Python a sequence of characters.
In Python, a string is enclosed in double quotes.
So if you want to create a sequence
of characters and the characters can be any character
that you can type on your keyboard.
So it could be letters, lowercase, uppercase,
could be numbers, could be special characters.
We just need to start and end with double quotes.
And if we do that and put it inside parentheses
we can print out that string.
So I'm gonna go back here just to make sure
that you can see.
Let me get rid of the red notation.
I wanna make sure that we can see that print starts
and ends with the parentheses.
What's inside the parentheses is what Python will attempt
to put as output.
Because I want to print out a string
I start it and end it with the double quote.
So they have to be inside the parentheses.
So all of these things are very important.
The order is very important.
First, the parentheses, then the double quote
to start the string, what's inside the string,
the double quote to end the string
and then the parentheses.
You can see that the double quote's not printed out.
The double quote's simply a signal to Python
where the string starts and ends.
So we don't actually have the double quote
to be printed out.
Let's change this line of code a bit
before we start creating some errors just to make sure
we understand strings, so I can change what's
inside the double quotes.
As I said, I can just type a bunch of nonsense, letters,
numbers, special characters.
There we go.
And I could run that and I get printed out all
of the different nonsense I put in there started and ended
with double quotes.
Now the other thing we could tell Python to print is
we can tell it to print out what's inside a variable.
So we can do that.
So let's do that.
Let's put in our variables that we created.
So I can say print and I could put x in there.
It runs fine, it prints
out what's inside x, the value.
Remember it's not printing the name of the variable.
Remember, variables have three features,
name, value and type.
Print is going to print out the value,
not the name, of the variable.
So when I say print x
it's gonna go inside x, inside the variable,
and print it out.
Print out what's in the the value of x.
Let me go back and say print y and I'm gonna get three.
The other cool thing
about print is we can print out two things at once.
We can separate them by a comma, print x and y.
So I can print that out
and you can see it prints out the value
of x first, 10, and then it prints out
the value of y, three.
Okay, so so far I have not created any errors.
So let's start creating some errors
and see what they look like in Python.
And again, you may have seen these already
but I'm gonna do them on purpose so
that we can figure out how to debug the errors and fix them.
And I'm gonna go back to the PowerPoint
for a second and just make sure
that everybody understands that we're gonna do here.
We're gonna do syntax errors.
They're gonna be violations of the rules of Python.
Okay, so let's go back to Python.
So let's do a violation.
First one is I'm going to do x equals 10 plus z.
Now my violation is there is no variable z, right?
There is no variable z.
So Python will gimme an an error message saying
that I made a mistake.
The name z is not defined.
So a couple things to know when you get this big...
So when you get an error in Python
it's like this big scary red block that comes
at you but but let's take some time to pick apart
what's in that red block so we understand what's going on.
So here's the big, red block.
It's called a trace back
because it's looking back at the code you ran.
We only have one line of code here,
zo it's not that complicated, the traceback,
but later the traceback will get more complicated.
It's telling us what kind of error, it's a name error.
That's the type of error we've created.
It's going to tell us that the error occurs in cell seven.
Well that's right, we're in cell seven, line one.
There's only one line.
So it's pretty simple.
But if we had many lines in cell seven,
remember you can have multiple lines of code in one cell,
it will tell us specifically what line the error occurs on.
So that's an important thing when you were debugging lots
of line of code here we only have one line
so it's not that interesting, but that's okay.
So it's telling, it's pointing, it will always have
this pointer here, this green pointer here.
It's telling, it's pointing us to that line
of code and it's giving us some help here.
And this actually is super helpful.
It's saying z's not defined.
So I can easily say, "Oh my goodness,
I didn't really want z, I really wanted y."
So look what happens when I correct my error
and I run it again, it goes away.
Error fixed.
So that is an example
of an error that's caused and I fix the error.
So let's create another error.
Let's do print (x y).
So I'm gonna forget the comma in the print.
And here I've created another error.
Again, it's going to tell me I have an error.
I know it's because it's got this red output here.
So that's an error.
It's going to tell me the error occurred
in line nine on line one, there's only one line,
so that's not that interesting.
But look at this very helpful error here.
It's saying perhaps you forgot a comma, it's a syntax error.
So that's super helpful.
So I can fix that error
by putting in a comma like that and running it.
And there we go.
We can create more errors.
I'll just do one more.
I can say print (X, y).
So here I am illustrating
to you that Python is case-sensitive.
So capital X and lowercase x are two different variables.
They're two different things in Python.
So here Python's going to look for a capital X variable
and it's going to tell me X is not defined, you know,
so it might take me a couple minutes to say,
"Wait a minute I defined x up here."
I did define x up here, but then I'll realize
that I defined it as a lowercase, not an uppercase.
So those are some simple syntax errors
that you might see when you're coding.
Let's create a logic error which is much harder to debug.
So I'm gonna go back to the PowerPoint
and just remind you that we've looked at syntax errors.
Those will give us that ugly red-looking block.
And Python will tell us, you know,
right in our face, "You made an error."
Semantic errors are much harder to fix.
There are logic errors.
Sometimes semantic errors will give us red output
but not normally.
Normally what happens
with a semantic error is we get output
but the output's wrong.
The output is wrong.
And we have to be a little bit more smart about looking
at our output and asking ourself is the output reasonable?
Is the output what we expected?
'Cause we have to catch the semantic errors.
Okay, so let's create a semantic error and see what happens.
So I'm gonna go back to our Module Six notebook.
Let me get rid of the blue ink.
Okay, so I'm going to get a fresh cell here.
Let's suppose we have a case where we have
to calculate sales tax, okay.
So I have to calculate sales tax.
I wanna calculate sales tax of an item.
So I'm gonna make two variables.
One's gonna be the item price
and one's gonna be the sales tax rate.
And then I'm gonna write some Python
to calculate the sales tax amount.
And I'm gonna create an error.
I'm gonna make a logic error,
a semantic error for this, okay?
So I'm gonna create a bunch of variables.
I'm gonna say the price of my item is $10.
I'm gonna say the sales tax rate is 6%.
So I'm here teaching, I live
and work in Pennsylvania and the United States
and we have sales tax on a lot of things, not everything,
but our sales tax rate is 6%.
So I would imagine that if I calculated sales tax correctly
on a $10 item in Pennsylvania
the sales tax would be 60 cents, right?
So I'm gonna go back here.
I'm gonna actually run this so I can create my variables
and then I'm going to do the math.
So I'm gonna say the tax amount.
So I'm gonna create a variable
like this, is price times rate, okay?
So a couple things I want you to know
that I did a little differently than I've done
in previous code is I've named my variables not x
and y and z.
So those are not really good names for variables.
They're good for learning what a variable is
and doing some quick and dirty creation of errors.
But in general we wanna give our variables much
more descriptive names.
So I've chosen price and rate
and tax amount as really good descriptive names
so I know exactly what those variables are going to hold.
In fact, I could even add comments to be even more specific
about what's in those variables.
Let me do that now before I create the error.
So let me go here after price
and put in a comment after, price of a purchased item.
And I'm gonna do sales tax rate in Pennsylvania.
PA is short for Pennsylvania in the United States.
So I'm gonna run this again.
And a couple things that you notice here is
before I showed you
that comments could go on a line by themselves
but they could also go after the code, perfectly legal.
And if you put them after the code
it kind of corresponds with the same line, right?
Like this is the comment that belongs to price.
This is the comment that belongs to rate.
So all of that's perfectly legal.
The other thing to notice here is that this
variable name I've used something that's called camel case.
Camel case is when you use a mixture
of upper and lowercase to name the variables.
So you cannot have spaces in variable names.
And here what I've done is made the a uppercase
to kind of make a distinction between two words
I'm putting together in the same variable name, okay?
So tax amount is camel case, okay?
So let us run this calculation of tax amount,
okay, ran fine, no errors.
I have no syntax errors.
So let me print out tax amount and see what I got.
Okay, so I got 60.
Clearly the sales tax on a $10 item is not $60.
So I have to say to myself, I have a logic error.
I don't have a syntax error 'cause I don't have
any red ugly output error messages in Python.
Instead I have a logic error.
A good way to catch logic errors is to think
about what your expected result is.
So I would go back here and before I ever ran this code
I would look at this and say that on a $10 item
at a 6% rate, my expected of tax amount would be 60 cents.
So now I can catch the error, I'm catching the error
because I'm comparing these two amounts.
I compare them and I say they are not equal.
I have a logic error, right?
And then I can go back and look at the code, right?
This code here and this code here.
So there's three lines of code I have to look
at here to catch the logic error, right?
This line and these lines.
And I have to think about what is the error.
Clearly the rate is not six, right?
The rate is 0.06 to actually capture the correct sales rate.
So that was my logic error.
So when I go back to correct that
I have to run all the lines of code again.
So I've gone back to correct, for me it was code snippet 13.
I've made a change in code snippet 13,
so I have to run code snippet 13 again and 14
and 15 and there I get my correct tax amount, 60 cents.
So I discovered the logic error, the semantic error
by again comparing, calculating my expected result
that I would get, then running the Python
getting the actual result.
So I'm comparing expected to actual,
so I'm gonna go back to the PowerPoint.
I'm checking expected versus actual there.
I'm checking that.
And once I find that in the expected
versus actual and I find that they're not equivalent
then I know need to go back to all the code I wrote
and think about where the error is, okay?
So I've gone over semantic and syntax errors here
and I will see you in the next module.
(upbeat music)