300 likes | 411 Vues
This document provides insights into common errors encountered while coding in Java, including syntax and compile-time errors caused by mismatched braces, missing semicolons, and type mismatches. It emphasizes the importance of debugging and showcases various strategies, including using print statements and assertions for efficient defect identification. Experienced programmers are significantly faster at finding errors compared to novices. The text also highlights the scientific method for debugging and encourages programmers to take responsibility for the errors in their code.
E N D
CS 498February 28, 2005 Errors and Bugs
Errors • Syntax errors and compile time errors • These occur as a results of your coding • 1) dropping or mismatching braces • 2) dropping semi-colons • 3) bad parameter lists • 4) mismatched types • sometimes you force this to work with type-casting – this can be a very dangerous
Bugs • Adm. Grace Hopper first used the term in software when a moth got stuck in a piece of hardware but… • Errors
Common Java Errors(java.about.com) A public class name doesn't match the filename
Common Java Errors(java.about.com) A class is not in the correct directory
Common Java Errors(java.about.com) Using equals versus assignment (== versus =)
Common Java Errors(java.about.com) Capitalization Java is case sensitive
Common Java Errors(java.about.com) Java is zero indexed
Common Java Errors(java.about.com) Null Pointers Use exception handling for null pointers Program defensively
Debugging(Code Complete) • Learn about the program • Learn about the kinds of mistakes YOU make • Learn about the quality of code you write from someone that has had to read it • Learn about how YOU solve problems • Lean about how you fix defects
Debugging • Experienced programmers are roughly 20x faster at finding defects than inexperienced programmers (Gilb, 1977; Curtis, 1981) 12 defects 3 Fastest 3 Slowest ------------------------------------------------------------------------- Debug time 5.0 14.1 Number NOT found 0.7 1.7 New introduced 3.0 7.7 (Gould, 1975)
Sherlock Holmes Eliminate the impossible and what remains, however improbable, is the answer.
Superstition • Bad compiler • Demon editor • Bad data • Etc
Take Responsibility If you wrote the program, you caused the error.
Debugging • Get more information • Programming dummies (lamp posting) • Source code debuggers • Hardware debuggers
Scientific Method • Gather data through experimentation • Form a hypothesis • Design an experiment • Prove or disprove the hypothesis • Repeat as needed
Gather information • Use prints statements or symbolic debuggers • Trace through code to find logic or flow errors
Form a hypothesis • Value is not being initialized which causes bad calculation
Design an experiment • Initialize values
Prove or Disprove • Run it • Examine results • Did it work?
Simple Things • Keep old versions • Make incremental changes • Set compiler warning level to highest possible • Treat warnings as errors
Simple Strategy You can do simple tracing by using print statements This is a crude and dangerous but used carefully, it can be useful
Print StatementsCons • Printing debugging information can muddy normal output • Could require an additional system to be added to you application • Some applications it won’t be useful at all • Can slow execution to a crawl (impractical) • Strings for your print statements change the contents of memory
Print StatementPros • Easy to implement • Can be easily removed • Can be written to disk for later examination
Print Statements • Use meaningful messages • WHERE in your code did this occur • WHEN – under what conditions • WHAT – data was being used
Assertions Allows you to test assumptions in your program. Typically, assertion-checking is enabled during program development and testing, and disabled for deployment.
Assertions “It is not illegal for a boolean expression contained in an assertion to have a side effect, but it is generally inappropriate, as it could cause program behavior to vary depending on whether assertions were enabled or disabled. “ http://java.sun.com/docs/books/jls/assert-spec.html
Assertions • Assertions should not be used for argument-checking in public methods. • Why not?
Assertions An assertion contains a boolean expression that you believe will be true Uses: Indicate code that should never be reached Detect out of range values Yahoo! Search: java assert http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
Resources(Code Complete) • Code Complete – Steve McConnell • Debugging: The 9 indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems – David J. Agans • The Art of Software Testing – Glenford J. Myers • Bug Patterns in Java – Eric Allen