1 / 30

CS 498 February 28, 2005

CS 498 February 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

harken
Download Presentation

CS 498 February 28, 2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 498February 28, 2005 Errors and Bugs

  2. 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

  3. Bugs • Adm. Grace Hopper first used the term in software when a moth got stuck in a piece of hardware but… • Errors

  4. Common Java Errors(java.about.com) A public class name doesn't match the filename

  5. Common Java Errors(java.about.com) A class is not in the correct directory

  6. Common Java Errors(java.about.com) Using equals versus assignment (== versus =)

  7. Common Java Errors(java.about.com) Capitalization Java is case sensitive

  8. Common Java Errors(java.about.com) Java is zero indexed

  9. Common Java Errors(java.about.com) Null Pointers Use exception handling for null pointers Program defensively

  10. 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

  11. 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)

  12. Sherlock Holmes Eliminate the impossible and what remains, however improbable, is the answer.

  13. Superstition • Bad compiler • Demon editor • Bad data • Etc

  14. Take Responsibility If you wrote the program, you caused the error.

  15. Debugging • Get more information • Programming dummies (lamp posting) • Source code debuggers • Hardware debuggers

  16. Scientific Method • Gather data through experimentation • Form a hypothesis • Design an experiment • Prove or disprove the hypothesis • Repeat as needed

  17. Gather information • Use prints statements or symbolic debuggers • Trace through code to find logic or flow errors

  18. Form a hypothesis • Value is not being initialized which causes bad calculation

  19. Design an experiment • Initialize values

  20. Prove or Disprove • Run it • Examine results • Did it work?

  21. Simple Things • Keep old versions • Make incremental changes • Set compiler warning level to highest possible • Treat warnings as errors

  22. Simple Strategy You can do simple tracing by using print statements This is a crude and dangerous but used carefully, it can be useful

  23. 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

  24. Print StatementPros • Easy to implement • Can be easily removed • Can be written to disk for later examination

  25. Print Statements • Use meaningful messages • WHERE in your code did this occur • WHEN – under what conditions • WHAT – data was being used

  26. Assertions Allows you to test assumptions in your program. Typically, assertion-checking is enabled during program development and testing, and disabled for deployment.

  27. 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

  28. Assertions • Assertions should not be used for argument-checking in public methods. • Why not?

  29. 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

  30. 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

More Related