Jun 16, 2014IAT 2651 Debugging

Dialectical Materialism  Dialectical materialism is a strand of Marxism, synthesizing Hegel's dialectics, which proposes that  Every economic order grows to a state of maximum efficiency, while simultaneously developing internal contradictions and weaknesses that contribute to its systemic decay Jun 16, 2014IAT 2652

Dialectics  Thus, programming is a dialectic process: –ENbugging –Debugging  Karl Marx said so! Jun 16, 2014IAT 2653

Jun 16, 2014IAT 2654 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 these get reported  Your program just doesn't do the right thing.

Jun 16, 2014IAT 2655 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

Jun 16, 2014IAT 2656 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.

Count Brackets and Braces { qwdkj { dw wqdlk lqwd { n,mnwq } } } Jun 16, 2014IAT Braces match if the last == 0!

Jun 16, 2014IAT 2658 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)

Jun 16, 2014IAT 2659 print your variables  println() –Use println often –Print everything: array values, pointer values, array index, objects etc –Each println should label itself with class name and line number –Java: Be sure to use System.out.flush(); to ensure you are getting all data

Jun 16, 2014IAT Learn to read your code  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 –Keep your code neat: save your mental effort for understanding, not reading

Always the Same Place  My keys are always the same place: –Right front pocket  My Java variables are always the same place –Top of method or top of class  Why? –I always know where to look for variables! Jun 16, 2014IAT 26511

Always the Same Place  For loops: always formatted the same  Switch: always formatted the same  Variables: I reuse the same names for( int i = 0 ; i < arr.size() ; i++ ) {... }  Doing it the same way every time Means: –You don’t have to read the whole for loop Jun 16, 2014IAT 26512

Always the Same Place  Here’s what you see: for( int i = 0 ; i < arr.size() ; i++ ) { }  Here’s what I see: for( int i = 0 ; i < arr.size() ; i++ ) { }  Here’s what I see when something’s missing: for int i = 0 ; i < arr.size() ; i++ ) { } Jun 16, 2014IAT 26513

Always the Same Place  Doing something the same way allows me to notice when something is different Jun 16, 2014IAT 26514

Jun 16, 2014IAT 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

Jun 16, 2014IAT Checked Exceptions  IOException (FileNotFoundException)  Input and output is typically hard 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

Jun 16, 2014IAT 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…

Jun 16, 2014IAT 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

Jun 16, 2014IAT 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

Jun 16, 2014IAT 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.

Wrong and Right  Build  Test  Build  Test  Build  Test  Build  Test  Build  Test Jun 16, 2014IAT 26521