He that would do a good job must sharpen his tools

Debug is one of the most effective methods in development when the results are inconsistent with what you expect. Of course, as development experience increases, it is sometimes possible to locate problems by looking directly at the code without debugging, but depending on experience and luck, local debugging is the most direct and thorough solution. Developed IDE from Eclipse to idea for a few years, work accumulated some debug commonly used methods, do a summary, the follow-up has a new posture to continue to supplement.

debug

Idea, debug is very simple, find you want to break point, click the left mouse button will appear a red ball, this hit on the breakpoint, debug mode to start the program, trigger you want to debug method, will help you stop in this line.

When debugging, there are various variables and expressions, some may not appear directly in the code, but it is important for you to debug, here you can use the expression calculator to help you verify the value of various expressions, without the need to manually calculate the value. Click on the calculator icon, then enter your expression, idea will help you calculate the value of the current expression.

Conditional breakpoints

Conditional breakpoints are one of the most common techniques used in debug. For example, a for loop, a recursion, or a line of code that is repeatedly entered in the same trigger, if there is no conditional breakpoint, you have to stop at this point as many times as possible, which is very troublesome. If you loop too many times, you almost cannot break at this point. Proportional loop 10000 times, abnormal can be concluded that the current running in 6378 out of the question, if you don’t change the code, in a row can not to interrupt point in the cycle, after the 6378 manual release to get to the, this time can only by changing the code, increase the 6378th judgment, and then a new code to get in on the debug. With a condition in place, we can set a Boolean condition on the breakpoint, which stops at the breakpoint only if the expression is true. For example, in the example above, if I is a loop from 0 to 4, we can set the condition “I == 3” so that the break point will only stop when I == 3. To set a conditional breakpoint, right-click on the breakpoint and enter your expression in the conditional

Note that when a conditional breakpoint is set, there is a small question mark in the lower right corner of the breakpoint icon; And when we run it, it doesn’t stop every time we get to this line of code, it only stops when I equals equals 3, so we can go right to the loop in question.

A single breakpoint

In cases where we want the breakpoint to be valid only once, we can set a single breakpoint. To set this up, go to “Breakpoints” (two red dots in the left sidebar), find your Breakpoints, and check “Remove once hit”.

Exception breakpoints

This is also a more common way to break points in development. Imagine ever encountered such a scene: after the operation to the null pointer exception or other what is unusual, but the current information on the stack is not to judge which line to quote, compare with traditional approach, hit a breakpoint at the beginning of the method, step by step, and then follow to go down, and see to which step can lead to abnormal operation, if the way is long, this way is time consuming. An exception breakpoint means that instead of setting a breakpoint on a particular line, you set a breakpoint on an exception. After the method is run, IDEA will help you stop at the line that caused the exception, making debugging much more efficient. To set an Exception breakpoint, first open “Breakpoints”, click “+” in the upper left corner, select “Java Exception Breakpoints”, and then search for the Exception you want to break point, if it is a custom Exception, you can select “Project”.

After this is set, the breakpoint flag does not appear on a particular line, because idea does not know which line will throw the exception before running. We make a null pointer exception to verify this, as shown in the figure below

When we start with debug, idea helps us stop at “s.length()”, where s is null, so it throws a null pointer exception, so we can use an exception breakpoint to directly let idea help us locate the line where the exception was thrown.

Forced return

Imagine ever encountering a situation like this: One way to debug exactly 10 lines, we already know the problem, then we may not want to execute that code, because the code may be writing database, remote call, send messages, if left behind code we will recover later will have trouble, then we are the most common operation directly stop, but unfortunately, After the stop, the following code will still be executed. As shown in the figure below, “this sentence will be executed after the for loop” will still be printed after the debug ends.

Is there a way to keep subsequent code from being executed? This is where you can use mandatory return. In the Frames module, find the method that is currently being Debug, right-click it, and select “Force Return”.

As shown in the figure below, “this sentence executes after the for loop” is not printed, proving that the following code is missing and has not been executed

PS: Some students’ idea may not open the frames module by default, you can choose to open the rubik’s cube here on the right

An exception is thrown

Sometimes we add trycatch where the method is called, or add uniform exception catching using AOP, but one time the result of the catch module is not what we expect, but our own test data does not cause exceptions, so it is difficult to debug the code of the catch module. In this case, we can force an exception to be thrown during the execution of the method, thus ensuring that we debug the code caught by the exception. This method is similar to the mandatory return method, by selecting throw and creating the desired exception in the expression:

As shown in the figure above, in method1, a null pointer exception is thrown. We catch this exception in the catch of the main method, so we can continue to debug the processing logic after catching the exception, as shown in the figure below

Drop Frame

In the debug process, sometimes the F8 press is one step too fast, resulting in the key line is not stopped, at this time we can only start again, if the branch is not easy to trigger, the cost of starting again is quite large, is there any way to backtrack? Of course, it doesn’t have the full functionality of the previous step, but using a drop Frame, you can make a submethod go through it again, to some extent. For example, in method1, we’re on line 2, but line 1 is our key line, so we can drop the frame of the method method1, so we’ll go back to where we called method1, so we can go in again.

The first time, we go through line 1 of Method1, currently on line 2, we select the Drop Frame in method1

At this point you fall back to where menthod1 was called

You can press F7 to re-enter method1

After executing the result, you can see that sout on line 1 of Method1 was indeed executed twice

Afterword.

Ok, let’s tidy up these first, next time new learn debug posture, then come here to supplement.