Identifying and Correcting Errors
Introduced| English |
|---|
| bug/bʌɡ/ |
| debugging/ˈdiːbʌɡɪŋ/ |
| syntax error/ˈsɪntæks ˈerə/ |
| logic error/ˈlɒdʒɪk ˈerə/ |
| runtime error/ˈrʌntaɪm ˈerə/ |
| overflow error/ˌəʊvəˈfləʊ ˈerə/ |
| edge case/edʒ keɪs/ |
| expected output/ekˈspektɪd ˈaʊtpʊt/ |
Every program has bugs
- No matter how careful the team is, programs contain mistakes.
- A mistake in a program is a bug 缺陷.
- Finding and fixing bugs is called debugging 调试.
- Skilled debugging is one of the most valuable abilities a programmer can build.
Which kind of error?
A syntax error stops the program running; a logic error runs but gives the wrong answer; a runtime error crashes it partway; an overflow error exceeds storage.
The work of finding and fixing mistakes in a program is called ______.
A mistake is a bug; fixing bugs is debugging.
A missing bracket that stops the program from running is a:
Breaking the language's rules is a syntax error.
Why are logic errors often the hardest to find?
Nothing obviously breaks, so you must compare output to what you expected.
The main kinds of error
- A syntax error 语法错误 breaks the language's rules (a missing bracket) — the program refuses to run.
- A logic error 逻辑错误 runs but gives the wrong result, because the instructions do not match the plan.
- A runtime error 运行时错误 crashes the program while it runs — like dividing by zero.
- An overflow error 溢出错误 happens when a value grows too large for its storage space.
Testing with edge cases (empty input, very large numbers) helps find hidden bugs.
Bugs often hide at the limits of what a program expects.
To spot a bug in a test, you compare the actual output with the:
A difference between actual and expected output points to a bug.
How to find them
- Test with many inputs, including unusual ones — a very large number, empty input, or an edge case 边界情况 at the limit.
- Compare the actual output with the expected output 预期输出; a difference points to a bug.
- Add temporary print statements to see internal values, so you find where it first goes wrong.
- Divide and check: confirm one part is correct, then narrow down the rest.
You should re-test the whole program after fixing a bug, since a fix can create a new bug.
Careful re-testing is what makes software trustworthy.
Fix, then re-test
- Logic errors are the hardest — nothing obviously "breaks," the answer is just wrong.
- Fixing one bug can create another.
- So after every correction, re-test the whole program.
- Careful, repeated testing turns a rough prototype into software people can trust.
"It ran" is not "it's correct." A logic error runs with no crash and no message — the program looks fine but the answer is wrong. The only way to catch it is to compare the output with what you expected, not just check that it ran.
A bug is a mistake; fixing bugs is debugging. A syntax error stops the program running, a logic error runs but gives the wrong answer, a runtime error crashes it partway, and an overflow error exceeds storage. Find bugs by testing many inputs (especially edge cases) against the expected output, and always re-test after a fix.