Using Error Messages

You can expect to make some errors.  Idle provides information about errors in several ways.  It provides information about the location and type of errors.  To be most useful, you want to be able to decode the errors.

To illustrate I start from a file that is purposefully incorrect to show off debugging ideas.

x = input("Enter a number")
y = x + 10
print('10 more is {}'.format(y)
print('Now we are done!')

I also have an initial documentation line.  If I try to run this I get

Syntax error highlights print

A popup Invalid Syntax window indicates the error was found by the interpreter in just trying to read the program - never getting to execution.  It highlights print in pink, indicating this is where is realized there was an error.  ( I left a number of blank lines in my program, so this image would show both the popup window and the highlighted code.)

You should know that print statements are perfectly legal.  There does not seem to be an issue with the word print.  Note carefully what I said earlier:  this is where the interpreter first noticed there was and error:  The actual error could be earlier - it just was not clear there was one yet.  The most common earlier place is the previous line, and I illustrated the most common such error.  The interpreter did not find an error on the previous line because it did not realize it was at the end of a statement.  When can a statement go on to the next line?  - When there are unmatched grouping characters, most commonly ( ).

It is very easy to have unmatched parentheses, particularly when there are many levels of pairs parentheses.  Recall that when you type in Idle it shows you what closing parentheses match with.  Here is the image just after I added the correct final ) at the end of the previous line:

matching paren higlighting

I did not show the progress in entering this program with its error.  Idle would have given a clue.  If we back up to when the first incorrect print line was entered, right after the enter key pressed, you would see

strange cursor jump
Note where the vertical bar cursor | jumped to:  not the beginning of the next line, where you would put the next statement.  If you look where it is positioned relative to the previous line, it is just after the unmatched opening (!  This is Idle's convention, so if you are paying attention to the automatic cursor indent, you should realize there was an error with unmatching delimiters, and see the issue.

Note that Idle also should give you warning of the opposite error: If you add an excess close parenthesis, you should hear a beep, indicating it was not expecting that character.

So now assume we have done this correction to the program, adding the closing parenthesis.  If we try to run again:

EOL string literal

Another syntax error, this time at the end of the last line, and with more information about the error.  EOL stands for "End Of Line",  so it got all the way to the end of the line reading a string literal.  The coloring also indicates this:  green all the way to the end of the line.  What does a string literal need at the end?  - A final matching quote character!  And we need a closing parenthesis, remembering our previous error.  Suppose I complete the line as

print('Now we are done!)')

I can now try to run again.  This time we do not get a popup syntax error window.  This means the interpreter did not find any errors.  Many errors are only found when running the program, so execution starts in the shell.  The program first prompts for a number, and I enter 100:

implict conversion error trace
We have a red error traceback.  In this case the"back" is not clear:  If there were many nested function calls we would see all the lines that called the next uncompleted function, plus the last line where the error was actually detected.  It shows the line

y = x + 10

In this little short program, it is easy to go back to the Python source and locate the line.  Idle also gives you help with this in general:  The next screen shows me right-clicking the mouse (or control-click on a Mac) on top of the red "line 14", where it is saying the error is.  This generates a popup window.

jump to error 1
The only allowed option is to select Go to file/line

jump to error 2

and then the focus jumps to the window with the source code, and highlights the desired line:

jump to error 3
So we have the line with the execution error.  We still need to figure out what is going on.  The bottom line in red gave a description of the error: 

TypeError:   Can't convert 'int' object to str implicitly.

Hm.  It is a type error, so look at the types.  It refers to an int.  Clearly we have 10.  There is something about a string.  The other data is x.  What is its type?  Of course the prompt in the previous line asks for a number, but what type is returned by the input function?  -- always a string!  So look at the expression again x + 10 -- a string plus a number  -- two different types, and it cannot convert so they are the same implicitly.  So we need to be explicit:  We want numeric addition, so we need two numbers, and the string must be explicitly converted.  You might need to look that up, but you have an idea what you are looking for:  we can use int as a function to convert the string.  We do not need to add an extra line -- we can make x start off as an int, changing the first line to

x = int(input("Enter a number"))

We can go a bit further:  though running the original first line by itself did not cause an error, looking at the output above, you can see it is ugly with the prompt running into the user response.  This is a logical error.  It is easy to correct, changing the first line so we have

fixed first line

Now run again:

output after first line fixes
One final logical error is the close parenthesis in the output.  I added a required final quote character on the last line, but I left an extra close parenthesis.  In "fixing" the last line earlier, I added another error.  This is unfortunately easy to do!  Final code:

last line fix

Final run:

last line output

So we have illustrated all three kinds of errors:
I chose common simple errors, so hopefully you would have been able to figure out the meaning of the error message.  That is a lot to expect in general.  We are only gradually adding explanations of bits of Python syntax.  You can easily make an error that Python interprets as being based on a more advanced feature, so the error message makes no sense to you. 

Even if you do understand the error message, you should get the information about where the error occurred.  Hopefully a concentrated look there will lead to you seeing the error and being able to correct it. 

Then there is a further useful step if you did not understand the original error message: Go back and consider it.  After seeing what was actually wrong, the error message may make sense now, AND that knowledge may be useful to speed up your understanding and your fix the next time you see that error message.

Particularly as a beginner, you can still hit a brick wall some of the time.  You are also in a course with an instructor:  that is the major reason I am here.   Ask for help!