## Want to keep learning?

This content is taken from the Raspberry Pi Foundation & National Centre for Computing Education's online course, Scratch to Python: Moving from Block- to Text-based Programming. Join the course to learn more.
2.5

## Raspberry Pi Foundation

Skip to 0 minutes and 3 seconds Scratch programs don’t really crash. But they might not do anything, or they might not do what is expected. But you won’t ever see an error message being spoken to you by the orange cat. Let’s have a look at this example. In this program, I want the value of the variable my_count cane to be outputted. But the my_count variable doesn’t exist. However, if I run the program, it runs, and I don’t see any errors.

Skip to 0 minutes and 32 seconds Text-based languages are a different story. And you can expect your program to crash fairly frequently. If we try and run the same example in Python, we see an error.

Skip to 0 minutes and 44 seconds Because the variable my_count doesn’t exist. A single misplaced quote, a missing colon, or even the wrong case letter, and your program will refuse to run. You can also see intimidating, sometimes barely comprehensible messages like this one. When your students see a message like this, they might wave their hand in the air and ask you why it’s not working. But with a little coaching and some careful explanation, you can help your learners develop the debugging skills that they need to fix the issues in their programs themselves. Let’s look at some examples of syntax errors.

Skip to 1 minute and 24 seconds In this example, we can see that there’s a missing colon here at the end of line 1. And if I still run this program, we can see that a syntax error is generated. And it gives us an indication, which is pretty good in terms of where the problem might be.

Skip to 1 minute and 40 seconds We can see in this example that there’s an extra bracket, an additional bracket at the end of this print statement. And again, if we run our program, we can see there’s a syntax error. And we get an indication that’s pretty good in terms of where the error might be. Now, this example is more difficult. The syntax error is here. We’re missing a square bracket at the end of our first list. However, if I was to run this program, again, we see a syntax error. But the indication is actually on the second line, and not on the first.

Skip to 2 minutes and 13 seconds So it’s important to look, not just on the line where the error is being generated, but also perhaps the one in front of it.

Skip to 2 minutes and 23 seconds Finally in this example, we can see that I have created a string starting with a single quote, but closed it with a double quote. Now when I run this program, again, we see a syntax error. But the description is “EOL while scanning string literal”, which isn’t particularly helpful or easy to say. Now, debugging becomes easier as you become more familiar with the Python language and understand the common errors that you make. How would you introduce debugging to learners new to text-based programming? Share your thoughts in the comments. In the next step, you will look at runtime and semantic errors.

# Errors

Scratch programs don’t really crash. They might not do anything, or they might not do what is expected, but you won’t ever see error messages being spoken to you by the orange cat.

Text-based languages are a different story, and it is important for learners to understand how to debug a text-based program when things go wrong.

When using a text-based language, you can expect your programs to crash fairly frequently. A single misplaced quotation mark, a missing colon, or a lower case letter where an upper case letter should be, and not only will your program refuse to run, but you’ll find that your IDE has suddenly been filled with red text that might be barely comprehensible and therefore intimidating:

Traceback (most recent call last):
File "/home/mjs/test.py", line 2, in
<module>
sleep ("10")
TypeError: an integer is required (got type str)


The moment a student new to Python sees such a thing, their most likely response will be to wave their hand in the air and ask you why it’s not working. However, with a little coaching and some careful explanation, you can help your learners develop the debugging skills they need to fix the issues in their programs themselves.

### Types of error

There are three types of error that can occur in a program: syntax errors, runtime errors, and semantic errors. The first is fairly simple to detect in any common programming interface. The second may be easy to spot, but this depends on the actual error. The last might be difficult to spot, but doing so gets easier with practise.

### Syntax errors

These occur when the programmer doesn’t follow the rules of the programming language. Sometimes the programming environment will simply refuse to even try and run the program.

#### Missing colon

Here is an example of a fairly simple syntax error in Python. The programming environment, in this case Mu, caught the error and refused to try and run the program.

The line where the problem has occurred is given in the error message and a ^ is used to indicate the position of the error. In this case, there’s a colon missing after the ) on line one.

Here’s another common error that is easily caught:

This error message occurs when the programmer enters two brackets where there should only be one.

#### Missing bracket

This one can be a little trickier.

Mu seems to suggest that the error is on line two. However, it’s actually the failure to close the square brackets on line one that is the problem.

#### Incorrect quotation mark

In this example the programmer has used a double quotation mark matched with a single quotation mark. Quotation marks should be the same around a single string — they are not interchangeable.

### Debugging discussion

Debugging becomes easier as you become more familiar with the Python language and understand the common errors you make.

• How would you introduce debugging to learners new to text-based programming? Share your thoughts in the comments.

In the next step you will look at runtime errors and semantic errors.