Eclipse Breakpoint Debugging

as a developer, it is necessary to master the debugging techniques in the development environment. Last year, I wanted to summarize the debugging of Eclipse breakpoints, because the degree of control over time still needs to be greatly improved, and the result is only written this post this year. There are a lot of Java debugging techniques, such as Java Debug interface, and so on, according to the needs of detailed projects, there are a lot of worth to study and study. This blog post is only a summary of the Eclipse breakpoint debugging techniques, not enough places to ask Daniel.

1 Debug View

1.1 Thread Stack View

The thread stack view represents the stack of the current thread, from which you can see what code is executing, and the entire calling procedure, along with the code line number. Explain the meaning of these buttons separately. From left to right, respectively:

1. Indicates that the current implementation continues execution until the next breakpoint, the shortcut key is F8.

2. Interrupt the entire process

3. The current method is entered, and the shortcut key is F5.

4. Indicates that the next line of code is executed, and the shortcut key is F6.

5. Means to exit the current method, return to the call layer, and the shortcut key to F7.

6. Indicates that the start of the current thread stack is returned at the beginning of the run.

1.2 Variable View

1. For the variable name view, displays all the available instance variables and local variables in the current line of code

2. Show all the variable values

3. Ability to change variable values through the form

1.3 Breakpoint View

1. Show All Breakpoints

2. Disable the port selected in the current form 1 and click Enable again.

3. Exception Breakpoint

Often meet some anomalies, and then the program will exit, to find the place where the exception occurred is more difficult, fortunately, can hit an abnormal breakpoint. Where the exception is, the current thread hangs.

1.4 Expression View

The expression view is a more frequently used view of the debug process, allowing you to observe some of the variables you are interested in, add some of your own expressions, and see the execution results of a line of code. 1. Expression 2. Click to add an expression.

2 Types of breakpoints

2.1 Method Breakpoint

Breakpoints Everyone is familiar with, in the Eclipse Java editing area of the wardrobe double-click to get a breakpoint, the code will be executed here when the stop. method Breakpoint is hit at the entrance of the method.

the special point of a method breakpoint is that it can hit the JDK source code, because the JDK at compile time to remove debugging information, so the normal breakpoint is not hit inside, but the method breakpoint can be, can be used to view the method of the call stack.

2.2 Conditional Breakpoint

Conditional breakpoints, as the name implies, is a breakpoint with certain conditions, only the conditions that satisfy the user settings, the code will be executed to the breakpoint at the time of the stop.

Right-click at the breakpoint and select the last "Breakpoint Properties"

There are three options in the breakpoint attribute, enabling "enable", hit count and conditional are selected according to our needs.

1) Hit count is how many times the code snippet at the specified breakpoint is run, most typically the loop, assuming that you want a loop to run 10 times on the thread to suspend, then specify the hits count value to 10, then the current loop runs to the nineth time when it hangs.

2)Conditional, as the name implies, is conditional inference, such as we need to loop variable i==10, thread hangs, the condition is set to i==10, select suspend when "true".

Assuming that the above hit count and conditional are selected, it would be practical to assume that the expression and value settings are unreasonable. Assuming suspend when value changes is selected, it is possible that the conditional will hang when the value of the variable has changed.

2.3 Variable Breakpoint

A breakpoint can not only be hit on a statement, but a variable can also accept a breakpoint.

is a variable of the breakpoint, the value of the variable initialization, or change the value of the variable can be stopped, of course, the variable breakpoint is also able to add conditions, and the above described conditional breakpoint settings are the same. Oh, this Part I did not go to practice, can not find where to set up ~

2.4 Changing the value of a variable

Change the value of the case for the code to stop at the breakpoint, but the value passed to the wrong, then you can change the value of the variable to ensure that the code to take the correct flow, or that there is an abnormal branch is always going to go, can not be debugged to change the conditions, to see if the exception Branch code is correct.

In the Variables small form of the debug view, we are able to right-click on the variable and select "Change Value ..." Change the value of the variable in the dialog box that pops up.

Or in the following values to view the changes in the form, save with Ctr+s, the value of the variable will become the new value after the change.

2.5 Debugging again

The rollback of such a debug is not omnipotent and can only be rolled back in the stack frame of the current thread, and it is said that it can only be returned at the beginning of the invocation of the current thread. on fallback, right-click on the thread method that needs to be rolled back, select "Drop to Frame"

about breakpoint debugging, there are exception breakpoints, etc., have been mentioned in the Dubug view, as well as remote debugging. I'm looking forward to the next blog post because I haven't tried it.

 

Eclipse Breakpoint Debugging