1. Nov 10, Fall 2006IAT 8001 Debugging

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

3. Nov 10, Fall 2006IAT 8003 Compiler Errors  Errors dealing with language syntax,  Simple logical errors, –Whatever the compiler can possibly catch.  Generally, the line number stated has the error on it. –Sometimes the fix is elsewhere

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

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

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

7. Nov 10, Fall 2006IAT 8007 Checked Exceptions  IOException (FileNotFoundException)  Input and output is typically hare to write because you have to deal with the real world’s complexities  Java requires that you put these in Try/Catch Blocks –Processing manages some of this

8. Nov 10, Fall 2006IAT 8008 Unchecked Exceptions  Exceptions that only the programmer can anticipate –Extremely hard for a compiler to determine  NullPointerException (NPE) and ArrayIndexOutOfBoundsException (AIOBE)  Caused by semantic errors –uninitialized variable, bad loop logic…

9. Nov 10, Fall 2006IAT 8009 Exceptions  On exception, you get a stack trace  Find the first line of the stack trace that occurs in your program.  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

10. Nov 10, Fall 2006IAT 80010 print your variables  System.out.println() (or println() in p5) –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

11. Nov 10, Fall 2006IAT 80011 Learn to read your code  Keep a notepad around to keep track of variable values. –Use commenst to document complex code –Keep one step to one line. –Format your code! Indentations help readability

12. Nov 10, Fall 2006IAT 80012 Things to remember  In java Objects are passed by reference and primitives are passed by value. public void doStuff(String a) { a = a + “bar”; } public void doMoreStuff(int a) { a = a+5; } public static void main(...){ String temp = “foo”; int temp2 = 5; doStuff(temp); doMoreStuff(temp2); System.out.println (temp); System.out.println (temp2); } prints out: foobar 5

13. Nov 10, Fall 2006IAT 80013 The #1 debugging tip  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.