1.4 Identifying and Correcting Errors

Errors! Gotta love them. Errors happen all the time when we're programming. The AP test will ask you to identify errors and you'll have to face them when making your Create task. Coding errors are also known as bugs, and they happen to everyone who's ever typed a line of code in their lives. Debugging is part of the coding process, so don't get discouraged if you come across some in your code. 

In this guide, we'll be discussing common errors, how to detect errors and how to fix them. We'll also be looking at how this topic will be tested on the AP Exam. 

Common Errors

Here's a list of common errors to get you started on your bug-hunting.

Syntax Errors: A syntax error occurs when the spelling and/or punctuation rules of the programming language aren't followed. For example, forgetting to close a set of parentheses or spelling a variable wrong, could cause your entire program to crash. A syntax error could also be failing to indent properly. This dependence on perfectly correct syntax can be one of the more frustrating things about coding. 

• Example: The syntax error is that I forgot to put a parenthesis at the very end of the code. My computer won't execute this statement unless I fix the syntax error.

Fortunately, many code editors will point out syntax errors, making them one of the easier errors to solve.

• Example: This code editor (Microsoft's Visual Studio Code) alerts me when I forget to close a parenthesis by making the unmatched parenthesis red. 

Logic Errors: A mistake in a program's base logic that causes unexpected behavior. Besides syntax errors or errors caused by the limits of the device you're running your code on, this category covers most other errors. 

• For example, a multiplication program outputs a result different from the expected value, saying that three times three equals thirty-three.

Run-Time Errors: An error that occurs when the program is running. You'll be able to start your program if you have a run-time error, but something will go wrong when you're trying to use it. 

• For example, let's say you have a dividing program, that takes two numbers (x and y) and divides x by y. Everything goes fine until you try dividing 5 by 0, after which the program crashes.
• Run-time errors can differ by programming language. Different programming languages have different rules and syntax, and therefore they may handle errors in different ways.

Overflow Errors: An error that occurs when a computer tries to handle a number that's outside of its defined range of values. Usually, this means that your computing device is trying to handle a number too big for it to process. 

• For more information, check out this explanation of Overflow Errors.

If you're working with a coding language and an error crashes your program, there will often be an error message displayed. In the example for a syntax error above, the error message started with SyntaxError, making it clear what the error was. 

However, error messages are not always so helpful. It's important to have many different methods to find and fix errors. Furthermore, bugs are tricky things, and it can be hard for even professional programmers to find and catch them all. (This is why a lot of software updates contain bug fixes. People are constantly finding and destroying bugs in their programs.) 

(Source: GIPHY from Reddit)

Error Fixes

So now that we know what the common errors are, how do we fix them? Here are some effective ways to identify, find, and correct errors. Not every method will be suited to every bug, and it's perfectly alright to mix and match them depending on what you need. 

• Testing different inputs, and testing at different points in your program's runtime. We'll talk more about testing in the section below.
• Hand tracing, or manually tracking your variables' values as your program goes along. Many hand-tracing methods use charts to organize these values. This method works well on basic code, such as the programs you'll see on the AP CSP exam, but as code gets longer and more complex hand tracing becomes very difficult to do.
• Using visualizations or visual representations of your code. If you’re working in a compatible language, try plugging in some code into this visualization tool to see how it works! Although they're helpful, you won't need to know how to use visualization tools for the AP test or to write your Create program.
• Using debuggers, or programs designed specially to test for bugs
• Adding extra print statements to your code to make sure that the "invisible" steps (the ones that aren't shown as output) are working properly.

Adding extra print statements is also a common way to test code. In this example, the numbers 5 and 7 are printed in order to make sure that the input system is working properly.

Testing

Testing is the process of making sure your code works. It sounds simple, but it's really hard, even for professional programmers. In this section, we'll be discussing common challenges people face when testing, and good practices to make testing easier and more thorough. 

Testing Challenges

Here are some challenges you might face as you're testing your code: 

• Complexity: The longer and more complicated your code is, the harder it is to test.
• Limited time and resources: Testing code can be challenging because it asks you to consider potential ways that the code could fail or produce incorrect results when it is used. There are often many possible scenarios that need to be taken into account, and sometimes we don't have the time, energy, resources, or all of the above to be as thorough as necessary.
• Unclear definitions: Before you can test code, you need to know what your program requirements are: in other words, what you want your code to do. You also need to know what your program needs in order to do that. - For example, a program that adds two numbers together needs two numbers in order to work.
• You also need to know what each section of code does and how it interacts with the other sections. If you don't quite understand your code, (and I've been there!), debugging it can be very difficult.

Good Testing Practices

Good testing procedures include testing with many different test cases. 

• Test cases at their most basic are a set of inputs and expected outputs for a program. - For example, the input 5 and 3 into an adding program yields the expected output 8.
• Ideally, you should write the test cases before you write your program. - This helps you understand what you're trying to accomplish with your program.
• You should test boundary cases or values on the edge of program limits. This is where errors are likely to happen. - For example, if your program only accepts values less than 9, you would check 8 and 10 as boundary cases.

There's a lot more that could be said about testing, but this is a pretty good start! Now, let's take a look at an example of error-fixing on the AP test.

Error-Hunting Example

Question courtesy of the AP CSP CED, updated for 2021.

Image source: AP CED, page 184

Give this problem a try!

Answer

The answer is C: Moving the statement in line 5 so that it appears between lines 2 and 3.

First, let's take a look at the program's purpose: returning the number of times the value val appears in a list. For example, if val equaled 5 and 5 showed up twice in the list imputed, the program would return 2.

Rewritten without the brackets, the code looks like this:

PROCEDURE countNumOccurences(myList, val) 

FOR EACH item IN myList 

    count ← 0 

    IF(item = val) 

        count ← count + 1 

RETURN(count)

Let's make a test list [5, 2, 3, 5] and set val equal to 5 to see what the error might be. The program should return a value of 2.

Starting from the beginning, we set the count to 0. The first number in the list equals the value of val, so count now equals 1.

Because we're in a loop (which we'll talk more about in Big Idea 3), you're going to go back through the loop for the second item in the list, which is 2. We set count to zero again, and...

Wait, that isn't supposed to happen! The error in this code is that every time the loop resets, count also resets to zero.

How would we fix that? By taking count ← 0 outside of the loop. We need it to be before the loop starts, so we have the count variable to work with, but it can't be inside the loop itself.

The loop begins in line 3, so putting count ← 0 between lines 2 and 3 works perfectly.

Whew!

That's a lot to take in, isn't it? Props to you for making it this far!

In our next Big Idea Guide, we'll cover data: how computers use and process it!