Types of Programming Errors Expanded
As first covered in lesson two, regardless of the programming language used, programming errors fall under three categories. As a programmer, you will first encounter syntax errors as you build your programs and either compile them or run them through the interpreter for the first time. Runtime errors and logic errors are typically uncovered later in the program development process while you are testing your programs. Below is a summary of each and a discussion of techniques useful in helping resolve each type of error.
Discussion of Program Syntax Errors
We introduced syntax errors in the last lesson. Syntax errors are caused when statements or expressions are inconsistent and cannot be executed by the interpreter or converted into machine code by the compiler. Common reasons for syntax errors are misspelled identifiers and keywords, invalid program grammar in expressions and statements (i.e. if arithmetic operators are used in an inconsistent manner). Errors that qualify syntax errors fall under a fairly broad category and each programming language treats syntax errors with varying levels of error detail. In other words, some programming languages provide syntax errors which are extremely informative and help easily isolate the problem. Other languages may not do much more than identify the offending line in the program.
Understanding Program Run-Time Errors
Once a program has been compiled or has a statement has passed through the interpreter without syntax errors, the program is available for execution. If during execution a value is processed or a resource is accessed in an inconsistent manner, the program stops execution and aborts with a runtime error. The error used most frequently discussed as a runtime error is when an expression tries to divide by zero. Any number divided by zero is mathematically indeterminate and because of this the computer is unable to return a value from the expression. When computer programs cannot execute program statements they will abort with a runtime error. If the runtime error is not processed as an exception, the program will need to be restarted from the beginning.
Learning about Program Logic Errors
Program logic errors have always been the most difficult errors to isolate. Logic errors do not return any error messages (syntax is okay) and do not stop execution of the program (a runtime error). When a logic error occurs the program appears to be functioning normally. It is only through rigorous testing that logic errors are caught by the programmer before creating a problem for the end user.
Sometimes the problems appear immediately but most of the time problems are not found until after the fact. For example, a calculation error on a particular product item may not be dramatic enough for the user to see the problem when it first happens. At month end, the department might see in sales summaries a sharp decrease in importance in sales. At this point the error might be a significant error and present a hardship to the organization. Only after returning to the software and reevaluating all the expressions and logic will you know if a logic error is present. This is the reason that why a test plan is so important as it helps to head off logic errors before they create bigger problems.
In Practice: Everyone will have a story about the logic error that got away - Sooner or later all of you will have a logic error you will never forget. As I mentioned earlier, it's perfectly acceptable and expected to make mistakes but the important thing is to learn from your mistakes and not let them happen again. My fondest memory of a logic error involved a programming language called RPG II (RPG stood for Report Generator language). RPG programs use the special variables called indicators to hold true or false values that indicated the outcome of the decision. You'll soon learn that all decisions processed by computer have only two outcomes, true or false. In my case, I had inserted a couple lines of logic which essentially provided special processing for a record that existed for one person a database of 20 thousand. This person had special processing performed on their monthly bill and was very vocal and adamant about having this special processing performed. As bad luck would have it, there always seemed to be a problem with processing data on this person's account.
In my haste to make a change to accommodate this person, I failed to do the testing necessary to validate that the change would work correctly. I'll have to admit that the test required a fair amount of time. I took a bit of a gamble and short cut my normal testing. As luck would have it, the logic failed and approximately 10,000 customer invoices carried a line on their monthly bill indicating a reduction of $10.00. The $10.00 didn't affect the invoiced amount but needless to say it created a lot of confusion when customers tried to reconcile their bill. I would say that I will always remember RPGII indicator 55 as my favorite logic error.