This chapter is from the book
This chapter is from the book
This chapter is from the book
The Debug Perspective
The default Debug perspective is made up of the following views:
-
Debug—This view is where you track and control the execution of your code (see Figure 3.1). You can have more than one program running at a time, and you can open or close the list of associated threads by double-clicking the selected program. Standard debugging functionality is also available through the buttons on the Debug view toolbar—you can pause, resume, kill, and disconnect processes as well as clear the view of any terminated processes. On any given line of code, you can also go into any given method or constructor (Step Into), execute the current line (Step Over), or leave the current execution point and return to the caller (Step Return). In addition, the Step With Filters/Step Debug feature allows you to step into a method, but skip any code that meets the filter criteria (for example, anything defined within a particular package could be skipped).
-
Variables—The Variables view displays the object and local variables available at the current position in the execution stack (see Figure 3.2). The top half of the view lists the variables, whereas the lower half displays the value of the selected variable. The menu bar for this view has five selections:
-
Display the type names next to the variable names
-
Display the logical structure
-
Select from one of the logical structures
-
Collapse an expanded node
-
A menu that allows you to change the orientation of the variable list to the Details window, turn Word Wrap on and off, display or hide constants, static variables, full package names, null array entries, and select how to display primitive data values (hex, ASCII, or unsigned)
-
Breakpoints—The Breakpoints view allows you to enable, disable, or remove listed breakpoints (one at a time or all at once). If you double-click a breakpoint, the file in which it is located will open to the location of the breakpoint. You can also set values such as the breakpoint hit count and display the breakpoint's properties by right- clicking the selected breakpoint.
-
Expressions—The Expressions view is similar to the Variables view except that you can arbitrarily add a variable or an expression for the debugger to display. The menu items available are the same as for the Variables view. This view is most valuable in displaying a variable that is changed by different levels of code.
-
Display—The Display view can be thought of as an extension of the Scrapbook page, only the results are displayed in the same view and are resolved within the context of the current stack frame. You can either cut and paste code from the current editor and execute, display, or inspect it (where inspecting the code opens the Expressions view) or you can type in code and then select and execute it.
){kind=small}
Figure 3.1 The Debug view displaying the running threads, the stack leading to the program's current location, and the current suspended thread.
){kind=small}
Figure 3.2 The Variables view displaying the running threads, the stack leading to the program's current location, and the current suspended thread.
The Variables, Breakpoints, and Expressions views are stacked in the top-right corner of the Debug perspective by default, but the Expressions view does not appear unless you select Window, Show View from the main menu. The Display view also does not appear unless you select it but rather opens in the lower part of the perspective. You are free to move or resize these views in any way you like. Three of the remaining views you have already seen and used (Outline, Console, and Tasks), leaving only the Progress view:
-
Progress—This view displays JVM activity while the process is running. Every line of code causes some activity in Eclipse as well as within itself.
The Debug perspective also contains an area reserved for editors. When you select an entry in the stack frame, the editor will jump to the location specified at the breakpoint in the correct level of the stack, if the code is available.
Using Debug Views Outside of the Debug Perspective
Eclipse makes no distinction between a view and the perspective in which it is displayed. Views are views are views: You can open other views in the Debug perspective (for example, the Package Explorer view), and you can open debug views (for example, the Variables view) in other perspectives. However, where other views could be helpful to have in Debug, the reverse is generally not true: Debug views are not of much value outside of the Debug perspective. Displaying the Debug view's current stack trace in the Java perspective or Registers in the Resource view does not help you to accomplish the task of debugging in an easier way.
Debugging as a Complement to Testing
To debug, or not to debug; that is the question. Bug-hunting can be a very satisfying part of the development process because it allows you to focus on a very specific problem-solving exercise, but it can also sometimes cause you to fail to see the forest for the trees. At this stage in the evolution of various development processes, it is easy to forget that without a good test suite in place, you will spend more and more of your time tracking down bugs than writing code. Try to think of debugging as a development tool to keep your tests working and not as a tool to keep your code working. Once you bypass the testing step, no amount of debugging is going to save you. Always have a test written to prove that a feature works as advertised, and use the debugger to help you figure out why a straightforward-looking piece of code is failing.
Without doing anything fancy, let's walk through debugging SimpleCalculator using as many of the debugger features as possible. Using the debugger in most other situations is similar, with the exception of necessary setup. For example, debugging server-side code assumes the server can either run within Eclipse or is available for a remote connection.