Identifying and Correcting Errors - AP Computer Science Principles Study Guide

Getting Started

No matter how carefully a program is planned, it will almost certainly contain errors. Creating successful software is not just about writing instructions for a computer, but also about becoming a detective who can systematically find and fix mistakes. This process of identifying and correcting errors is a fundamental skill in all areas of computing, ensuring that programs are reliable, accurate, and behave as intended.

What You Should Be Able to Do

• Describe the difference between logic, syntax, and run-time errors.

• Identify the type of error present in a segment of code.

• Use a code trace to follow an algorithm's execution and identify a logic error.

• Develop a set of test cases to verify a program's correctness.

• Explain the process of debugging to find and fix errors.

Key Concepts & Application

The Core Idea

In programming, an error is often called a "bug." The process of finding and fixing these bugs is a core part of software development. Imagine you are following a recipe. A syntax error is like a misspelled word or a missing instruction step; the recipe is unreadable and you can't even start cooking. A run-time error is like being told to use an oven when you don't have one; you have to stop cooking unexpectedly in the middle of the process. A logic error is the most subtle: the recipe has no typos and all the steps are possible, but a mistake in an ingredient amount (e.g., "1 tablespoon of salt" instead of "1 teaspoon") results in a final dish that is technically complete but tastes completely wrong.

Computer science formalizes the "tasting" and "fixing" of the recipe into two practices. Testing is the process of trying out the program with various inputs to see if it produces the correct output. Debugging is the methodical process of finding the specific cause of a known error and correcting it.

Logic & Application

To create reliable programs, we must understand the different kinds of errors we might encounter.

Types of Errors

Annotated Pseudocode Examples

The most challenging errors to find are often logic errors, as the program appears to work correctly.

// EXAMPLE 1: LOGIC ERROR

// This procedure is intended to calculate the average of two numbers.

PROCEDURE calculateAverage (num1, num2)

{

  sum <- num1 - num2      // Logic Error: Should be addition (+), not subtraction (-).

  average <- sum / 2

  RETURN(average)

}

• Analysis: This program will run without crashing. However, if you call calculateAverage(10, 6), it will incorrectly return 2 instead of the correct average, 8. The algorithm is flawed, but the computer executes the flawed instructions perfectly.

// EXAMPLE 2: POTENTIAL RUN-TIME ERROR

// This procedure calculates a ratio based on user input.

PROCEDURE calculateRatio (total, count)

{

  IF (count = 0)

  {

    // Without this check, a run-time error would occur if count was 0.

    DISPLAY("Cannot calculate a ratio with a count of zero.")

  }

  ELSE

  {

    ratio <- total / count

    RETURN(ratio)

  }

}

• Analysis: Dividing by zero is an impossible operation that causes a run-time error. Good programming practice involves anticipating these situations and adding checks (like the IF statement here) to prevent the program from attempting an operation that would cause it to crash.

Tracing & Analysis

Logic Trace

A trace is a powerful debugging technique where you manually track the values of variables as a program executes, line by line. Let's trace the flawed calculateAverage procedure with inputs num1 = 10 and num2 = 6.

The trace clearly shows that the final output is 2. By comparing this to the expected output of 8, we can confirm a logic error exists and pinpoint the line sum <- num1 - num2 as the source of the problem.

The Role of Testing

To find errors, we use test cases—specific inputs designed to check the program's behavior. A good set of test cases checks for various scenarios:

• Expected Inputs: Values you would normally expect (e.g., testing a calculator with 2 + 2).

• Boundary Cases: Values at the edge of what is allowed (e.g., testing a grading program with scores of 0 and 100).

• Invalid or Unexpected Inputs: Values the program should handle gracefully (e.g., testing a program that expects a number with text input or a negative value).

Core Concepts & Terminology

• Error: A mistake in a program, also known as a "bug," that prevents it from functioning as intended.

• Logic Error: A flaw in a program's design or algorithm that causes it to produce incorrect or unexpected results, even though the program runs without crashing.

• Syntax Error: A mistake that violates the grammatical rules of a programming language, preventing the program from being translated and run.

• Run-time Error: An error that occurs while the program is executing, often due to impossible operations like dividing by zero, which causes the program to halt.

• Testing: The systematic process of executing a program with various inputs to identify any differences between the actual and expected results, thereby revealing errors.

• Debugging: The methodical process of identifying the root cause of a known error (a bug) and correcting the code to resolve it.

• Core Logic: Tracing: Manually stepping through an algorithm line by line to track the values of variables and determine the program's execution flow and final output.

  
  x <- 10
  
  y <- 5
  
  x <- x + y
  
  // A trace would show x becoming 15 at this line.
  

  Tracing is a fundamental debugging technique for finding logic errors.

Core Skill Check

• Logic Tracing: What is the final value of score after this pseudocode runs: score <- 10; REPEAT 2 TIMES { score <- score + 5 }?

• Debugging: Identify the logic error in this pseudocode, which is intended to check if a user is a teenager (ages 13-19): IF (age > 13 AND age < 19) { RETURN(true) }.

• Application: Describe two test cases you would use to find errors in an algorithm designed to calculate the shipping cost for a package, where weights from 1 to 50 lbs are valid.

Common Misconceptions & Clarifications

• "If a program runs, it must be correct."

  • Clarification: A program can run without crashing but still produce the wrong answer. This is a logic error, which is often the most difficult type of error to find because the computer gives no warning.

• "Testing just means running the program once."

  • Clarification: Effective testing involves using a well-designed set of multiple test cases, including typical inputs, boundary values (e.g., 0, -1, max value), and even unexpected data types to ensure the program is robust.

• "Debugging and testing are the same thing."

  • Clarification: Testing is the process of finding that an error exists (e.g., noticing the output is wrong). Debugging is the process of locating the specific cause and fixing that known error.

• "Syntax errors are the hardest to fix."

  • Clarification: While frustrating, syntax errors are often the easiest to fix because the computer usually tells you the exact location of the mistake. Logic errors are much harder because the program runs, but silently produces the wrong result.

Summary

Writing code is an iterative process that always involves finding and fixing errors. All programs are susceptible to three main types of errors: syntax errors that prevent the program from running, run-time errors that cause it to crash during execution, and logic errors that cause it to produce incorrect results. To build reliable software, developers use a systematic approach. They perform testing by running the program with a variety of well-chosen test cases to discover if bugs exist. Once a bug is found, they engage in debugging, often using techniques like code tracing, to locate the source of the error and correct it. This cycle of coding, testing, and debugging is fundamental to computer science.