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 needed For example, key = Integer.parseInt(st.nextToken()); is split into String token = st.nextToken(); key = Integer.parseInt(token);

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 creation (we see object, not the init method of applet, on the Debug view), let ’ s Step Return to come back from within the method. Step Into again, now we will enter “ into ” the run() method of the Console class

From here Step Return: will go out of run(), but not really since it encounters the next breakpoint first. Step Into: will go into frame creation, we don ’ t want this because it is not part of our code. But if we go past this part, we can Step Into the title() method-> not much 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 not much point). Let ’ s Step Over until we are at init() method of the applet.

Here we can Step Into the init() method, or Step Over, but won ’ t get pass because we will encounter breakpoint first. At the for loop, let us try to step over. As expected, 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 through 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