1 / 6

Correcting Run-Time Errors

Correcting Run-Time Errors. Small changes and the “What did you just change?” rule Look at the stack Use the debugger Compare against other code Look up Java documentation. These are all recommended practices – not necessarily in order!.

teige
Download Presentation

Correcting Run-Time Errors

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. Correcting Run-Time Errors • Small changes and the “What did you just change?” rule • Look at the stack • Use the debugger • Compare against other code • Look up Java documentation These are all recommended practices – not necessarily in order!

  2. Small changes and the “What did you just change?” rule • Only make a few changes, then compile and test. • This hugely simplifies debugging. • Saves you lots of time in the end. • Gives you tremendous confidence in your code. • The first corollary to this rule is this: • The error is always in the last thing you did. • Which, if you follow the rule, is easy to spot!

  3. Look at the stack • Example Java run-time exception dump: --------------------Configuration: <Default>-------------------- This tests the method written, above. Your input is: asdf You entered : asdf Exception in thread "main" java.lang.NumberFormatException: For input string: "asdf" at java.lang.NumberFormatException.forInputString(NumberFormat Exception.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at LittleTest.main(LittleTest.java:49) Process completed.  The last visible thing the program did – also a clue!  Here’s the Java run-time exception dump!  The top line number shown – always a strong clue! And – What kind of error was it? – In this case, a “NumberFormatException” – maybe “asdf” isn’t numeric?

  4. Use the debugger • We’ll do a demo momentarily. • Key activities: • Make sure “Include debug info” is set.(can be set at the time of creating a project or later in Configure… Options…JDK Tools… Default… Parameters also in Project… Project Properties… JDK Tools) • Likewise – be sure “View… Other Windows… Debug View” is on. • Set breakpoints of interest, to stop the program. • Start the debugger. • Watch the yellow carat – It’s where you are! • Dump selected values by highlighting fields, then “Dump”. • Step or Continue the program.

  5. Compare against other code • My new Transformer class def starts with: • public class CountDowner implements StringTransformable • But all the other Transformer classes start like: • public class Capitalizer extends StringTransformer implements StringTransformable • Maybe that’s why I’m getting this – ? Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: CountDowner at StringTransformers.add(StringTransformers.java:46)

  6. Look up Java documentation • What’s that “Integer.parseInt(…” really do?(back in the Java dump on slide 3) • Where would you look in the Java Docs?Checking the documentation is not the last resort, but a good recommendation to end on! Class Integer, method parseInt( ) (Not that a preposition is ever good to end on…)

More Related