Android Development Note "Eclipse Debugging and Shortcut Keys"

Original address: http://blog.sina.com.cn/s/blog_5cf876340100aswr.html

Eclipse Debugger and Debug view

The Eclipse SDK is a project for the Java™ development tool (Java™development TOOLS,JDT), which has a built-in Java debugger that provides all the standard debugging features, including step-through execution, setting breakpoints and values, checking variables and values, Suspend and resume the functionality of the thread. In addition, you can debug applications running on remote machines. The Eclipse platform is robust because other programming languages can use the debugging tools provided by the platform for the respective language runtime. As shown below, the same Eclipse Debug view can also be used with the C + + programming language.

The Eclipse Platform Workbench and its tools are built around the JDT component, which provides the following features for Eclipse:

• Project Management Tools
• Perspectives and views
• constructors, editors, search, and build features
• Debugger

The Eclipse debugger itself is a standard set of plugins within Eclipse. Eclipse also has a special debug view that is used to manage debugging or running programs in the workbench. It can display the stack frame of a suspended thread in each debug target. Each thread in the program appears as a node in the tree, and the Debug view shows the process for each running target. If a thread is in a suspended state, its stack frame is displayed as a child element.

before using the Eclipse debugger, assume that you have installed the appropriate Java SDK/JRE (I recommend using Java VM V1.4) and the Eclipse Platform SDK V3.3, and that both work fine. In general, it is better to test the debugging options with the Eclipse sample first. If you want to develop and debug a C + + project, you will also need to obtain and install the C + + development tool (C + + development TOOLS,CDT). See reference resources for Java SDK/JRE, Eclipse platforms and samples, and CDT . Figure 1 shows a general view of the Debug perspective.

Figure 1. General view of the Eclipse Debug perspective

Debugging Java Language Programs

You need to cleanly compile and run the code at the moment you can debug the item. First, you need to create a run configuration for your application to ensure that the application starts correctly. You then need to set up the Debug configuration in a similar way through the Run > Debug menu. You also need to select a class to use as the primary Java class for debugging (see Figure 2). You can set up multiple debug configurations for a single project as you wish. When the debugger starts (from Run > Debug), it opens in a new window, where you can start debugging.

Figure 2. To set the main Java class for a project in a debug configuration

Next, you'll discuss some of the common debugging practices in Eclipse.

Set breakpoints

When you start the application for debugging, Eclipse automatically switches to the debug perspective. Undoubtedly, the most common debugging step is to set breakpoints so that you can check for variables and values within a conditional statement or loop. To set a breakpoint in the Java Perspective's Package Explorer view, double-click the selected source code file and open it in an editor. To traverse the code, place the mouse over the tag bar of the suspect code line (to the left of the editor area) and double-click to set the breakpoint.

Figure 3. Two breakpoints seen on the left side of the editor

Now start the debug session from the Run > Debug menu. It is best not to put multiple statements on one line, because you cannot step in and set a line breakpoint on multiple statements on the same line.

Figure 4. The arrow at the left margin in the view indicates the row that is currently executing

There is also a handy breakpoint view to manage all breakpoints.

Figure 5. Breakpoint View

Conditional breakpoint

Once you know where the error occurred, you may want to know what the program is doing before the program crashes. One way is to step through each line of the program's statement. Execute one line at a time until you run to the suspect line of code. Sometimes it's best to run only a piece of code, stop running at the suspect code, and check the data at this location. You can also declare conditional breakpoints, which are triggered when the value of an expression changes (see Figure 6). In addition, you can also use code help when entering conditional expressions.

Figure 6. Set conditional breakpoint triggers

Evaluate the value of an expression

To calculate the value of an expression in the editor of the Debug perspective, select the line of code that sets the breakpoint, and in the context menu, select the Inspect option by ctrl+shift+i or right-clicking the variable you are interested in (see Figure 7). The value of an expression is evaluated in the context of the current stack frame, and results are displayed in the Expressions view of the display window.

Figure 7. To calculate the value of an expression by using the Inspect option

Cut activity Code

The Display view allows you to manipulate the activity code in a cut-type manner (see Figure 8). To process a variable, enter the variable name in the Display view and the view will prompt you for a familiar content helper.

Figure 8. Display View

When the debugger stops at a breakpoint, you can continue the debugger session by selecting the Step over option from the Debug View toolbar (see Figure 9). The higher the line of code that is displayed, the more expensive the operation continues to execute the next line of code in the same method (or proceed to the next line of code that calls the method that called the current method). Variables that change after the previous step are highlighted in a certain color (yellow by default). Colors can be changed in the Debug Preferences page.

Figure 9. Variable to change color

To suspend the execution thread in the Debug view, select a running thread, and click Suspendin the Debug View toolbar. The current call stack for the thread is displayed, and the currently executing line of code is highlighted in the editor in the Debug perspective. When a thread is suspended, the mouse is placed on a variable in the Java editor, and the value of the variable is displayed in a small hover window. At this point, the top stack frame of the thread is also automatically selected, and the visible variables are also displayed in the Variables view. You can check the variable by clicking the appropriate variable name in the Variables view.

Hot swap bug FIX: Dynamic code correction

If you are running Java Virtual machine (Java MACHINE,JVM) V1.4 or later, Eclipse supports a feature called Hot Swap bug fix (hotswap Bug fixing), which is not supported by JVM V1.3 or a lower version. This feature allows you to change the source code in a debugger session, which is better than exiting the application, changing the code, recompiling, and then starting another debugging session. To take advantage of this feature, you can re-debug your code after you change it in the editor. This functionality is possible because the JVM V1.4 is compatible with the Java Platform Debugger architecture (Java Platform Debugger architecture,jpda). JPDA implements the ability to replace modified code in a running application. This is especially useful if the application starts longer or if it takes a long time to execute to the point where the program failed.

If the program has not been fully executed while debugging is complete, select the Terminate option in the context menu of the debug view. An easy mistake is to use Debug or Run instead of Resume in a debugger session. Doing so will start another debugger session instead of continuing the current session.

from IBM;



1.Step into (also F5) jump
2.Step over (also F6) skip
3.Step return (also F7) executes the current method, and then return jumps out of this method
4.step filter Progressive filtering is performed until an unfiltered position or breakpoint is encountered (set Filter:window-preferences-java-debug-step Filtering)
5.resume restarts debug and runs until breakpoint is encountered.
For example: A and B two breakpoints, the debug process found a breakpoint is useless, remove a breakpoint, run resume will skip a directly to the B breakpoint.
6.hit count set execution times for a for loop in the program (set breakpoint view-right-click count)
7.inspect check operation. Executes an expression that displays the execution value
8.watch real-time monitoring of changes to objects, methods, or variables

9. The breakpoint (breakpoints) We often say is the line breakpoints, except for line breakpoints, there are other types of breakpoints: field (Watchpoint) Breakpoint,method Breakpoint, exception breakpoint.
10.field Breakpoint also known as watchpoint (monitoring point) suspend when member variable is read or modified
11. Add method Breakpoint Suspend (Run-method breakpoint) when entering/leaving this approach
12. Add exception breakpoint Catch the Execption when the suspension (to be continued ...)
Breakpoint Properties:
1.hit count execution number of times after suspend for loop
2.enable condition meet your input criteria (for ture\ change) on hold
3.suspend thread Multi-threaded when this threads are suspended
4.suspend VM suspend Virtual machine

Variables in the 13.variables view can change the value of the variable, and the variables view selects the variable right-click--change value. Once for quick commissioning.
The 14.debug process modifies some code after the--〉save&build-->resume--> is re-suspended on the breakpoint

15.resume when debug debugging runs out of exception, run resume and start debugging again from the breakpoint
16. If a row has many methods,
When the first time you press F5 key to jump into this line first method, F6 step by step debugging, F7 out of this method.
When the second press F5 key to jump into this line the second method, F6 step by step debugging, F7 jump out of this method.
And so on. To enter this line the first few methods, just a few times F5 and F7.

Android Development Note "Eclipse Debugging and Shortcut Keys"