If you have been a programmer for a while, chances are that you are familiar with the classic debugging technique known as trace code. In case you are not familiar with trace code, let's break it down for you. In this debugging technique we introduce println or print statements throughout the code under inspection in order to show information regarding variables or whether the program has taken a certain path. With this definition in mind, you might be wondering, why would you need a debugger? The answer is simple and twofold. First, using a debugger you can achieve the same results without too much fuss. When applying trace code, you need to include print statements, recompile the program (or the particular chunk under inspection), run, and analyze the output of the trace code. Also, after finding the bug, you have to remove all trace code. Without mentioning that whenever a bug appears, you have to repeat the procedure all over again. Trace code is a cumbersome technique. In contrast, when using a debugger, achieving all that is just several clicks away. Second, you can get a lot more from debuggers; they allow you to peruse aspects of your program that would be quite difficult to figure out just by looking at the output.

As we mentioned, Eclipse ships with a full-blown debugger. This built-in Java debugger provides all debugging support functionality; it is possible to execute programs step-by-step, set breakpoints, inspect variables and values, and pause and resume threads.

There are many ways to launch a Java program in the debug mode. One option is to select the Java class file with the main method that you want to debug in the Package Explorer view and then click on the Debug [] button in the workbench toolbar (or select Run | Debug from the workbench menu bar). It is also possible to achieve the same thing by selecting Run | Debug as | Java Application from the workbench menu bar, or by clicking on Debug as | Java Application in the Package Explorer pop-up menu or in the drop-down menu on the Debug toolbar button. During debugging activities, Eclipse switches to the Debug Perspective, but before switching to it, the window shown in the following screenshot asks whether you want to change from the current perspective to the Debug Perspective.

When you click on yes, the Debug Perspective appears, as illustrated in the following screenshot. This perspective allows you to control all threads of execution of the program under inspection. In the Debug Perspective: the call stack in the top-left corner indicates the methods of your program that were invoked, in the top-right corner you can manage the breakpoints and inspect the content of variables. These views are updated as you interact with your running program by stepping through its execution and adding and removing breakpoints.

The basic way of interacting with the debugger is by setting breakpoints. A breakpoint is a way of indicating to the debugger the line of code where you want the execution to pause. To set a breakpoint, while in the Java perspective, select the source code file you want to debug and open it in the editor (by double-clicking ). Skim through the code and place your cursor on the marker bar, which is along the left-hand side edge of the editor area, on the line that you want execution to stop. Then, double-click to set the breakpoint. Alternatively, you can right-click on this position and select Toggle Breakpoint.

Once a breakpoint is hit, Eclipse pauses the execution, and the line containing the breakpoint is highlighted, which gives you a visual feedback of the next line that will be executed. This gives you a chance to examine the state of variables, and so on.

To resume execution after hitting a breakpoint, click on the Resume button in the Debug view's toolbar. This button makes the program execute until completion or proceed until it reaches the next breakpoint.

Aimed at inspecting the behavior of your program, Eclipse Debugger allows for stepping into the code line by line through the program execution. This can be done through two commands: step into (F5) and step over (F6). The difference between these two commands is only noticeable when the next instruction is a method call. Selecting step over makes the debugger execute the method (without entering it) and proceed to the next statement following the method call. It is worth mentioning that even though the debugger does not show the method's body, it will be executed normally. On the other hand, if you choose the step into command, the debugger will proceed to the first line of the underlying method.

After stepping into a method call it is still possible to skip the rest of it: use the step return command (F7). The debugger will proceed to the next line after the method call. The following table gives an overview of the main commands in the Debug toolbar.

Icon	Description
	Disable all breakpoints.
	Resume execution.
	Stop the current debug session by terminating the current execution.
	Proceed to the next statement of the program under inspection. If the next statement is a method call, this command will step into the method body code.
	Proceed to the next statement of the program under inspection. If the next statement is a method call, this command will execute the method body without entering it.
	Exit the current method and go to the calling code.
	Re-enters the selected stack frame in the Debug view. Since it relies on the existence of an stack frame, it is not possible to use this option when debugging native methods.

As you step through your program execution, it is also possible to peruse and modify the state of your program. You can examine the contents of local variables, parameters, and visible fields by looking at the Variables window. It is also possible to investigate the contents of a variable by hovering the mouse pointer over it in the Java editor. As for non-primitive variables, they can be expanded in order to examine their individual elements. Apart from inspecting the value of variables, you can also examine the value of Java expressions in the editor in the Debug Perspective. Select an expression, then right-click on it, and choose Display. Eclipse evaluates the selected expression, taking the current scope into account, and shows the result in a pop-up window.

During a debug session, you can also modify the value of variables. To do so, select the variable that you want to modify in the Variables view; this will make its value appear in the bottom-half window of the Variables view, so that you can edit it. After editing, right-click and choose Assign Value.

Let's say that during your debug session you found a bug, and luckily, you also know how to fix it right away. Do you need to stop the debug session to start fixing the program? The answer is no. Thanks to a feature called hot code replace, editing and debugging can be carried out in tandem; you can edit your program without having to stop your debug session. The only side effect is that after modifying a method, Eclipse has to throw away the previous stack frame and begin the method again from the first line.

We covered the main functionalities of the debugger, now, armed with this debugging knowledge, go back and try to pinpoint the problem with testAddResultToTempAt.