07Debugging

07Debugging - CS108, Stanford Winter 2010 Handout #7 Young...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
CS108, Stanford Handout #7 Winter 2010 Young Debugging Handout written by Nick Parlante Attitude Mindset - It appears hopeless, but there is a logical structure in there. The evidence will be obscure, but consistent in pointing to the guilty code. - Avoid "deer in the headlights" -- debugging is the state of mind that although it appears impossible, you can sift through it. - Don't panic -- be methodical. Somehow the TA is able to do this, and they don't know more about your code than you do. Symptom -> Code - You observe a symptom -- bad output, an exception. - You track from the symptom backwards through the code path to the bug. Symptom back to bug The bug is in the code at point. The bug causes bad data, wrong function calls, etc. to happen going forwards, eventually causing symptom. The debugging task, in essence, is a backtracking task, starting from the symptom point and working back upstream to find the causing bug. bug symptom bad data code - Great questions These questions will solve most bugs: What method shows the symptom? What lines of code produces that symptom? What is the state of the receiver object in that code? What were the param values passed in? (a breakpoint is a quick way of seeing all those values) If it's an exception, what does the exception error message say -- null pointer? array access? Sometimes the exception name can be very informative. Eclipse debugger On an exception -- use the debugger to look at the object ivars and method variables and parameters (the questions above) -- just use "Debug" instead of "Run" in Eclipse to start your program all the time. The debugger is good at letting you look at things without having to put in printlns or anything. To see state at a particular line, put in a breakpoint (double-click at the left)
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 Println() Println is another way to see state (ivars and params) Println is especially good if you want to see the state 20 times in succession in a loop -- the debugger is not as good at that For a complex object, take a minute to override toString() so you can just print the whole object whenever you want. Debugging Mechanics.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 01/12/2010 for the course CS 108 taught by Professor Jimenez during the Winter '08 term at Stanford.

Page1 / 3

07Debugging - CS108, Stanford Winter 2010 Handout #7 Young...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online