music

OSdata.com

listing and errors

summary

    Compilers can produce listings. These will add extra information to your original source code file. Many compilers have optional settings on what kinds of information are included. Of particular interest are errors. There are two basic kinds of errors in programming: (1) errors in typing a language and (2) errors in programming logic.

free computer programming text book project table of contents If you like the idea of this project, then please donate some money. more information on donating

listings and errors

    Compilers can produce listings. These will add extra information to your original source code file. Many compilers have optional settings on what kinds of information are included.

    Of particular interest are errors. There are two basic kinds of errors in programming: (1) errors in typing a language and (2) errors in programming logic.

    A mistake in a program is called a bug. This is an old engineering term, appearing in Thomas Edison’s writings:

    “It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and then that ‘Bugs’ — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.” —Thomas Edison

    Many books incorrectly attribute the term “bug” to Grace Hopper. While she was working at Harvard University’s Computation Laboratory, operators discovered a moth trapped in a relay in Harvard’s Mark II computer. The moth was taped to the log book. Hopper repeated the story for decades as the case of the first actual bug in a computer.

    A compiler generated listing will only show errors in the typing (such as mistakes in spelling or punctuation) or incorrect use of the language (such as incorrect formation of an executable statement). These are known as compile time errors because they can be identified at the time the program is compiled.

    You won’t know about errors in programming logic until the program is actually running. These are known as run time errors. You will want to thoroughly test your programs to try to find any mistakes, but testing won’t always reveal every error. There is an art to testing a program. Some of the best program testers don’t even knw how to write a program, but they sure know how to find ways to break programs.

    Errors vary in severity. In some cases the compiler may be able to correct errors of low severity for you. Some compilers let you control which errors are flagged, skipping over errors the compiler can correct. You should strive to eliminate all errors from your source code listing, even if the compiler is able to correct them for you.

    Compilers also often produce warning. These are things that are not necessarily a problem. Some compilers let you decide whether to have warnings listed or not, and in some cases even let you decide which kinds of warnings are listed. You should strive to eliminate all warnings from your source code listing.

    Many compilers have the option of inserting line numbers into your listing. These line numbers can be very useful in tracking down compile time errors. Note that it is rare that the compiler’s idea of line numbers will end up exactly matching the physical lines in your original source file. The line numbers are typically based on the language’s statements. Comments and blank lines are rarely counted as lines in a source code listing. Multiple statements on a single line are usually identified by the number of the first statement on the same physical line.

    Many compilers will give you the option of stopping after the first error is detected or attemting to continue to compile. Note that the first error may confuse the compiler enough that it starts reporting bogus errors. This is known as cascading errors (named after cascading waterfalls).

    Many compilers will give you the option of viewing the symbol table. This is a list of the identifiers (procedures, functions, labels, constants, variables, etc.). There are many uses for a symbol table in correcting your source code. As one example, it is possible that you misspelled an identifier. The code may be correct from a lexical point of view (with no errors listed), but won’t work at run time. You might spot the incorrect spelling in your symbol table.

    You may want to purposely introduce a few errors into your Hello World program and see how your compiler reports them.

    Compilers are notorious for cryptic error messages. The error messages are generally not standardized for any particualr language, but vary with each compiler. With practice, you will learn to read the error messages and use them to find and identify your mistakes.

    A few days after initially writing this chapter, I spoke to a man who had been a BASIC programmer during the 1980s. He recounted that he had attempted to write a FORTRAN program and spent three weeks trying to track down a single error: accidently replacing a period with a comma. Sadly, this is typical of the debugging abilities of most programmers. There are very few places in FORTRAN where replacing a period with a comma will still produce a running program. It really shouldn’t have taken more than a few minutes to track down the exact line with the error and then identify the incorrect character through visual examination. If the program did compile and run, it shouldn’t have taken too much time to pin down the location of the error and then spot the incorrect character. Being methodical is a great way to not only locate bugs but also to avoid them in the first place.

    While software errors may be inevitable, good programming practices can dramatically lower the number of errors.

    Structured programming was created as a method to eliminate programming errors. It tended to eliminate many errors caused by sloppy coding and reduced the complexity of some kinds of programming to the point that mistakes were less common.

    Object oriented programming was created to both allow for faster creation of complex software and to reduce the number of mistakes in complex software. While these characteristics do apply to skilled programmers, for the vast majority of current programming, object oriented programming doesn’t actually cut down on errors, but instead limits the damage of errors. That is, a typical programmer will still make as many mistakes as ever, but the mistakes will be isolated and won’t cause havoc on the larger system.

other

   “40. There are two ways to write error-free programs; only the third one works.” —Alan Perlis, Epigrams on Programming, ACM’s SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13

   “61. In programming, as in everything else, to be in error is to be reborn.” —Alan Perlis, Epigrams on Programming, ACM’s SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13

---