The exception stack is the most important means for us to locate problems in daily life, and it provides us with great help in solving problems. But we may all have the habit of seeing an exception, especially when there are many exception stacks and deep levels.
I felt very worried and scared. I quickly scanned it and started to guess what the problem should be, and then continued to guess based on it. Adjusting the code, although debugging is also possible, still wastes a lot of time.
This is because:
1. We did not read the exception stack information carefully;
2. There are too many stacks. We're not sure exactly what's causing the problem.
The solution is:
1. Know the process of exception stack generation.
2. Read the stack information patiently.
3. Solve the problem
1. Exception generation process: The above error is reported, and the following follows
For example: We have the following test code
package com.bsx.test; public class TestException { public static void main(String[] args) { TestException exception = new TestException(); exception.m1(); } public void m1() { m2(); } public void m2() { m3(); } public void m3() { String name = null; System.out.println(name.length()); } }
After execution, the output result is as follows:
Exception in thread "main" java.lang.NullPointerException at com.bsx.test.TestException.m3(TestException.java:22) at com.bsx.test.TestException.m2(TestException.java:17) at com.bsx.test.TestException.m1(TestException.java:13) at com.bsx.test.TestException.main(TestException.java:9)
We can see that the order of the error log output is opposite to the calling order. Why?
We know that Java methods are executed in the virtual machine stack when executed. Each time a method is executed, a new stack frame will be created and pushed into the virtual machine stack.
This is a last-in-first-out structure, so when an error is reported, the error is reported from the callee first, and then the caller reports an error in sequence. Therefore, the order when printing errors is also that the error position is at the top, and the caller Row backwards. From this we can draw the conclusion: the error is reported above, and the following follows.
2. Understand the error message: Find the location where our code reports the error
From the above analysis, we know that the error location is above. In most cases, the error message at the top is where the error occurred in our code.
But sometimes the top log is not our own code. That is because our code calls the code of some third-party jar packages. But this does not affect us in locating the problem. We still locate the problem based on the error reported above and follow below. Then the real error location is still above.
Then we only need to find our own code from top to bottom. The first location of our code found is the location in our code that caused the error. Sometimes some error messages are obvious, and we can directly locate the crux of the problem based on the error messages.
Sometimes the error message does not clearly indicate the cause of the error. At this time, we can set a breakpoint at this precise location to debug it.
The above is the detailed content of How to locate the location where an exception occurs in the exception stack in java. For more information, please follow other related articles on the PHP Chinese website!