Jun 16, 2014IAT 2651 Debugging. Dialectical Materialism Dialectical materialism is a strand of Marxism, synthesizing Hegel's dialectics, which proposes.

Jun 16, 2014 IAT 265 1

IAT 265

Debugging

Dialectical Materialism

g Dialectical materialism is a strand of Marxism, synthesizing Hegel's dialectics, which proposes that

g 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

g Thus, programming is a dialectic process:– ENbugging– Debugging

g Karl Marx said so!

Jun 16, 2014 IAT 265 3

IAT 265 4Jun 16, 2014

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 these get reportedg Your program just doesn't do the right

thing.

IAT 265 5Jun 16, 2014

Compiler Errors

g Errors dealing with language syntaxg 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

IAT 265 6Jun 16, 2014

How to fix compiler errors?

g Start at the top of the error listg 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.

Count Brackets and Braces

{ qwdkj { dw wqdlk lqwd { n,mnwq } } }

Jun 16, 2014 IAT 265 7

1

2

3

2

1

0

Braces match if the last == 0!

IAT 265 8Jun 16, 2014

Compile Time Errors

g Some errors aren't necessarily errors.– For example:

String foo; //assume we initialize this somewhere elsepublic 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)

IAT 265 9Jun 16, 2014

print your variables

g 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

IAT 265 10Jun 16, 2014

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– Keep your code neat: save your

mental effort for understanding, not reading

Always the Same Placeg My keys are always the same place:

– Right front pocketg My Java variables are always the

same place– Top of method or top of class

g Why?– I always know where to look for

variables!

Jun 16, 2014 IAT 265 11

Always the Same Place

g For loops: always formatted the same

g Switch: always formatted the sameg Variables: I reuse the same names

for( int i = 0 ; i < arr.size() ; i++ ) { ... }g 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 Placeg Here’s what you see:

for( int i = 0 ; i < arr.size() ; i++ ) {}

g Here’s what I see:for( int i = 0 ; i < arr.size() ; i++ ) {}

g 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

g Doing something the same way allows me to notice when something is different

Jun 16, 2014 IAT 265 14

IAT 265 15Jun 16, 2014

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

IAT 265 16Jun 16, 2014

Checked Exceptions

g IOException (FileNotFoundException)g Input and output is typically hard 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

IAT 265 17Jun 16, 2014

Unchecked Exceptions

g Exceptions that only the programmer can anticipate– Extremely hard for a compiler to

determineg NullPointerException (NPE) and

ArrayIndexOutOfBoundsException (AIOBE)

g Caused by semantic errors– uninitialized variable, bad loop logic…

IAT 265 18Jun 16, 2014

Exceptions

g On exception, you get a stack traceg 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

IAT 265 19Jun 16, 2014

Things to remember

g 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:

foobar5

IAT 265 20Jun 16, 2014

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.

Wrong and Right

g Buildg Buildg Buildg Buildg Buildg Buildg Test

g Buildg Testg Buildg Testg Buildg Testg Buildg Test

Jun 16, 2014 IAT 265 21