IAT 265
Debugging
Jun 16, 2014
IAT 265
1
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, 2014
IAT 265
2
Dialectics
 Thus,
programming is a dialectic process:
– ENbugging
– Debugging
 Karl
Jun 16, 2014
Marx said so!
IAT 265
3
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
Jun 16, 2014
program just doesn't do the right thing.
IAT 265
4
Compiler Errors
 Errors
dealing with language syntax
 Simple logical errors
– Whatever the compiler can possibly catch.
 Generally,
error on it
the line number stated has the
– Sometimes the fix is elsewhere
Jun 16, 2014
IAT 265
5
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.
Jun 16, 2014
IAT 265
6
Count Brackets and
Braces
{ qwdkj
{ dw wqdlk lqwd
{ n,mnwq
}
}
}
Jun 16, 2014
1
2
3
2
1
0
Braces match if the
last == 0!
IAT 265
7
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, 2014
IAT 265
8
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, 2014
IAT 265
9
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
Jun 16, 2014
IAT 265
10
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, 2014
IAT 265
11
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, 2014
IAT 265
12
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, 2014
IAT 265
13
Always the Same Place
 Doing
something the same way allows me
to notice when something is different
Jun 16, 2014
IAT 265
14
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, 2014
IAT 265
15
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, 2014
IAT 265
16
Unchecked Exceptions
 Exceptions
anticipate
that only the programmer can
– Extremely hard for a compiler to determine
 NullPointerException
(NPE) and
ArrayIndexOutOfBoundsException (AIOBE)
 Caused by semantic errors
– uninitialized variable, bad loop logic…
Jun 16, 2014
IAT 265
17
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, 2014
IAT 265
18
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, 2014
IAT 265
19
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.
Jun 16, 2014
IAT 265
20
Wrong and Right
Build
 Build
 Build
 Build
 Build
 Build
 Test

Jun 16, 2014
Build
 Test
 Build
 Test
 Build
 Test
 Build
 Test

IAT 265
21