Introduction
Hi, it’s me again, the direct personification of FiveHive(/j).
In this article, we will be going over the learning objectives for 1.4, as outlined in the AP CSP CED.
- CRD-2.I - For errors in an algorithm or program:
- CRD-2.J - Identify inputs and corresponding expected outputs or behaviors that can be used to check the correctness of an algorithm or program.
First, let us get into errors.
Common Errors in Programming
We’re gonna go over four common types of programming errors: logic, syntax, run-time, and overflow errors.
A logic error is an error that arises from a mistake in an algorithm or program that causes it to behave wrongly.
For example, say someone makes a program that is meant to count apples, sort them by color, and open the bottom to drop only green ones. If the programmer made a mistake when programming, and the program dropped all the red ones instead, this would be a logic error. The program works just fine, but not as the developer expected. It’s an error in the logic.
Next, a syntax error is an error in which the developer makes a mistake following the rules of a programming language. In C++, not using a semicolon at the end of a statement is a syntax error.
A run-time error is one where something goes wrong during execution of the program. A very famous example of this is dividing by zero. Languages have different ways to handle these errors, since they have different rules and syntax.
Finally, an overflow error is an error when a computer attempts to handle a number outside of the defined range of values. For example, in C++, if you set up a signed short(an integer, signed basically means it can go to negatives), you can store any integer from -32768 to 32767. If you try to add one to this variable that holds the integer value 32,767, the number will wrap around to -32,768. Basically, if your program is trying to handle a number “too big” for it, an overflow error will occur.
Correcting Errors
Now that you understand the types of errors, we can work on locating and correcting them. There are many ways to accomplish this, but I’ll show you five (for FiveHive!!).
-
Test Cases
- Testing for if a specific condition is met. You might have a test for if an email is formatted correctly in a login system.
-
Hand Tracing
- Basically where you just follow the steps the program should follow manually. You might set up a way to track variables on paper, and follow how the value of these values changes throughout the program.
-
Visualizations
- This just visualizes your code, not super important in CSP.
-
Debuggers
- Debuggers are just programs made to test your program for bugs. These are usually built into IDEs (like Visual Studio)
-
Adding extra output statements
- This one’s simple, you just add print-out statements to check if specific, non-visible parts of your program are actually running.
Testing
“In the development process, testing uses defined inputs to ensure that an algorithm or program is producing the expected outcomes.” -CED
In other words, you give the program an input that you know should produce a specific output, and make sure that it gives you the output you want. You use the results from this testing to alter or fix your program. These inputs should demonstrate different expected outcomes; they should be just at or beyond the minimum and maximum values for input data. To identify the appropriate defined inputs for this testing, you need program requirements (see 1.3)