Logical Errors Cause Gray Hair

The third and final classification of errors consists of errors caused by faulty logic. Logical errors have the potential to live unnoticed for a long period of time; this is because your application will, from all outward appearances, appear to work just fine. Logical errors aren't discovered by the compiler at development or compile time and they don't embarrass you by displaying terse run-time errors to your end users. Though most logical errors are found and don't cause serious problems, some logical errors can be extremely difficult to find and have the potential to do great harm depending on what your application is used for.

Let me give you an example. Perhaps you have a reporting routine that performs some calculations. Logical errors in your calculations may be causing your report to be reporting flawed numbers. Unless the numbers are tied out or reconciled against some other source or against manual calculations, no one may ever notice the logical error. Your program will appear to run with nary a hiccup. If your report is used as a primary source of information for important decisions, what would the impact be to the decision making process if the numbers were flawed?

For logical errors, detection is the primary concern. You can't fix anything if you don't know it is broken. Thus we come to rule number four.

Debugging Rule #4: Test. Test. Test. Although you also want to detect any run-time errors lurking in your program, it is more important to focus on detecting logical errors by comparing the output of critical parts of your program against output that comes from another source or that is manually calculated and validated.

0 0

Post a comment