Debugging in Java

Common Bugs Compilation or syntactical errors

are the first that you will encounter and the easiest to debug They are usually the result of typing errors.

Logic errors different from run-time errors because there are no exceptions

thrown, but the output still does not appear as it should These errors can range from buffer overflows to memory

leaks. Run-time errors

occur during the execution of the program and typically generate Java exceptions

Threading errors are the most difficult to replicate and track down.

How to Debug a Program Identify the statement that causes the problem Set breakpoint on that line Run the program with debugging mode The program will stop at the defined breakpoint Trace through the program – using step into,

step return, step over, etc. Inspect the variables that may cause the

problem Identify the problem if possible or repeat the

tracing until the problem is found

Set Breakpoint Breakpoints are temporary markers you

place in your program to tell the debugger where to stop your program execution

You could set a breakpoint on the line containing the statement

Execution stops at the breakpoint before the statement is executed

You can then check the contents of variables, registers, storage and the stack, then step over (or execute) the statement to see how the problem arises

Types of Breakpoints Line breakpoints

are triggered before the code at a particular line in a program is executed

Method breakpoints are triggered when a method that has been set as a

breakpoint is reached Counter breakpoints

are triggered when a counter assumes or goes beyond a particular value

Exception breakpoints are triggered when code throws a particular type of exception

Storage change breakpoints are triggered when the storage within a particular storage

address range is changed Address breakpoints

are triggered when the address a breakpoint is set for has been reached.

Stepping Through a Program After you have set your breakpoints,

begin executing code in the debugger When the first breakpoint is hit, you

can step over statements, step into other methods or classes, continue running until the next breakpoint is reached, or continue running until you reach the end of the program

Stepping in a debugger Stepping into executes the current line. If

the current line contains a call to a method, the execution traverses to the first line in the called method. If the method is in a class that was not compiled with debug information, you will see a No Source Available message

Stepping over executes the current line without stopping in any functions or routines called within the line

Step return executes from the current execution point up to the line immediately following the line that called the current method

Inspecting variables Typically a program is core dumping because a

value of a variable is not set correctly Visual debuggers usually have a monitoring window

where they display the values of all the variables local to the current class that you are currently in

Some debuggers even display the address of the variable and may even let you dynamically change the value to see if the program will continue to execute as you originally expected it to

You can even investigate the entire contents of an array by displaying every row and column's contents

Debugging with system.out.println()

It is the simplest way of debugging a piece of small code

System.out.println() displays messages, variables, and state information on the console or where ever you redirect your output during run time

Other Debugging Techniques

Observe the program behavior by inserting printing statements along the main flow and exceptional flows

Split the compound statement if neededFor example, key = Integer.parseInt(st.nextToken());is split into String token = st.nextToken();

key = Integer.parseInt(token);

Using Eclipse to Debug

Using Eclipse to Debug

Set breakpoint

Run->Debug As->Java Application

Stop at each breakpoint

Method to be debugged

Variables to be inspected

Resume, Pause, Stop, Step Filter, Step into, Step over, Step return

Array Variables

Watch and Change Variable Value

Watch Variables

Using Scrapbook to test

Typing Source Code to Execute in Scrapbook

Scrapbook execution & import

Example dubugging

Then, Run->Debug As->Java Application

Step Into: will go into object creatio n (we see <init> object, not the init

method of applet, on the Debug vie w), let’s Step Return to come back f rom within the method.

Step Into again, now we will enter “i nto” the run() method of the Consol

e class

From here Step Return: will go out of run(), but not r

eally since it encounters the next breakp oint first.

Step Into: will go into frame creation, we don’t want this because it is not part of o

ur code. But if we go past this part, we ca - n Step Into the title() method > not muc h there anyway.

Step Over: will go to the next line. Now we’re at SetupClosing(). We can Step

Into or Step Over (or Step Return, but no t much point). Let’s Step Over until we a

re at init() method of the applet.

Here we can Step Into the init() method, or Step Over, but won’t get pass because w

e will encounter breakpoint first. At the for loop, let us try to step over. As ex

pected, we will be in the loop for quite a while. But look on the top right :) You see

the value that changes as you go throug h the loop.

To evaluate any expression, type it in the Display view, then right click it and choose Display. The Display view will show the value. The expression can be something a bit more complicated, like msg.charAt(i) i.e expression that does not exist in actual code.

Or we can choose Inspect, which will also add this expression to the watchlist in Expression view.

But the Display view is not updated as you go through the code. The value of any expression added to the watchlist from the Display view is also not updated. But we can make this work (in the Expression view) by..(see in a couple of pages).

How to make the expression update itself