Seven common tips for debugging bugs in Eclipse

1. Conditional breakpoint

Breakpoints everyone is familiar with, in the Eclipse Java editing area of the wardrobe double-click to get a breakpoint, the code will run here when the stop.

A conditional breakpoint, as the name implies, is a breakpoint with a certain condition, and the code will stop when it runs to the breakpoint only if the user set conditions are met.

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

The property interface of the breakpoint and the meaning of each option,

2. 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, in the value of the variable initialization, or change the value of the variable can be stopped, of course, the variable breakpoint can also be conditional, and the above described conditional breakpoint settings are the same.

3. Method Breakpoint

The method breakpoint is to hit the breakpoint at the entrance of the method,

The special point of the method breakpoint is that it can be hit in 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, this method can be used to view the call stack.

4. Change the value of the variable

The code stops at the breakpoint, but the value passed is not correct, how to modify the value of the variable to ensure that the code to continue the correct process, or that there is an abnormal branch is always going to go, can you debug the condition, to see if the abnormal branch code is correct?

In the Variables small window of the debug view, we can see that the value of the Mdestjarname variable is "F:\Study\eclipsepro\JarDir\jarHelp.jar"

We can right-click on the variable and select "Change Value ..." Modify the value of the variable in the popup dialog box,

Or in the following values to view the changes in the window, save the Ctr+s saved, the value of the variable will be changed to a new value.

5. Re-commissioning

The fallback for this debug is not omnipotent and can only be rolled back in the current thread's stack frame, and can be returned at most to the beginning of the invocation of the current thread.

On fallback, right-click on the thread method that requires fallback and select Drop to Frame

6. Remote Debugging

For debugging programs that are not on this computer, there are two ways to

1, the machine as a client

2, the machine as a service side

The premise of using remote debugging is that the server side and client code are consistent.

This machine acts as a client

This machine is commonly used by the client, the Java program on the remote server needs to open the remote debug switch at startup,

Server-side need to add virtual machine parameters

1.5 Previous version (1.5 also available later): "-xdebug-xrunjdwp:transport=dt_socket,server=y,address=8000"

Version 1.5 and above: "-agentlib:jdwp=transport=dt_socket,server=y,address=8000"

F:\study\eclipsepro\screensnap>java-xdebug-xrunjdwp:transport=dt_socket,server=y,address=8000-jar Screensnap3.jar

When connecting to a remote server, you need to create a new remote debugger in eclipse

There is a small place to note that the connection on the time does not seem to automatically switch to the debug view, do not think that the local debug program is not connected to the server side.

This machine serves as the service side

You only need to modify the "Connection Type" as a client compared to the native machine.

At this point eclipse will enter the state of waiting for the connection

The connection program uses the following parameters to connect to the local server, IP address should be replaced by implementing IP ~ ~

"-agentlib:jdwp=transport=dt_socket,suspend=y,address=127.0.0.1:8000"

F:\study\eclipsepro\screensnap>java-agentlib:jdwp=transport=dt_socket,suspend=y,address=127.0.0.1:8000-jar Screensnap3.jar

While remote debugging, local code modifications can be synchronized to remote, but will not be written to remote files, that is, local modifications will be the next time you start the remote program, will not affect the next use of remote code.

7. Abnormal 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,

We have added a Nullpointexception exception breakpoint, and when the exception occurs, the code stops at the occurrence of the exception and should be helpful when locating the problem.

Seven common tips for debugging bugs in Eclipse