IAT 800 Debugging Nov 12 2009 IAT 800

IAT 800 Debugging Nov 12, 2009 IAT 800 1

How do I know my program is broken? g Compiler Errors – easy to fix! g Runtime Exceptions – more difficult to fix, but at least you're using java and you get these g Your Nov 12, 2009 program just doesn't do the right thing. IAT 800 2

Compiler Errors g Errors dealing with language syntax, g Simple logical errors, – Whatever the compiler can possibly catch. g Generally, the line number stated has the error on it. – Sometimes the fix is elsewhere Nov 12, 2009 IAT 800 3

How to fix compiler errors? g Start at the top of the error list g Some errors cause others – Wrong variable declaration causes errors in usage of that variable g Use the line number! g If that line looks OK, check the line above – maybe missed a brace/semicolon or other necessary syntax element. Nov 12, 2009 IAT 800 4

Compile Time Errors g Some errors aren't necessarily errors. – For example: String foo; //assume we initialize this somewhere else public void blah(){ Object bar; try{ bar = foo. to. String(); } catch(Exception e){ println(“Oh no!!”); return; } println(bar. to. String()); //lets call this line 101 } – Will give you something like: line 101: variable bar might not be initialized! (or something like that) Nov 12, 2009 IAT 800 5

Runtime Exceptions g There are two types of Runtime Exceptions – Checked and Unchecked g Checked exceptions: – Java makes you deal with these in your code – Things that you would expect to fail: I/O mainly g Unchecked exceptions – Java does not require you to catch these Nov 12, 2009 IAT 800 6

Checked Exceptions g IOException (File. Not. Found. Exception) g Input and output is typically hare to write because you have to deal with the real world’s complexities g Java requires that you put these in Try/Catch Blocks – Processing manages some of this Nov 12, 2009 IAT 800 7

Unchecked Exceptions g Exceptions anticipate that only the programmer can – Extremely hard for a compiler to determine g Null. Pointer. Exception (NPE) and Array. Index. Out. Of. Bounds. Exception (AIOBE) g Caused by semantic errors – uninitialized variable, bad loop logic… Nov 12, 2009 IAT 800 8

Exceptions g On exception, you get a stack trace g Find the first line of the stack trace that occurs in your program. g That line is where the exception occurred, not necessarily where the fix is. – On that line, did you get an NPE? – Is there some object that you're calling a method on? Is that object Null? – For AIOBE, check index values Nov 12, 2009 IAT 800 9

print your variables g System. out. println() Processing) (or println() in – Use println often – Print everything: array values, pointer values, array index, objects etc – Each println should label itself with class name and line number – Be sure to use System. out. flush(); to ensure you are getting all data Nov 12, 2009 IAT 800 10

Learn to read your code g Keep a notepad around to keep track of variable values. – Use comments to document complex code – Keep one step to one line. – Format your code! Indentations help readability Nov 12, 2009 IAT 800 11

Things to remember g In java Objects are passed by reference and primitives are passed by value. public void do. Stuff(String a) { a = a + “bar”; public void do. More. Stuff(int a) { a = a+5; } } public static void main(. . . ){ String temp = “foo”; int temp 2 = 5; do. Stuff(temp); do. More. Stuff(temp 2); System. out. println (temp 2); } prints out: foobar 5 Nov 12, 2009 IAT 800 12

The #1 debugging tip g. TEST YOUR CODE OFTEN! – Catching your small errors early will help you avoid the big complicated errors later. – If you write a chunk of code that you can test, test it. – You'll regret not spending 5 minutes writing a simple test case when you spend hours trying to find out it has a bug later. Nov 12, 2009 IAT 800 13