75

For example, I got a stack trace like this:

java.lang.NullPointerException
abc.investxa.presentation.controllers.UnixServerJobController.handleRequest(UnixServerJobController.java:66)
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)

So what is the root cause of this exception? From the stack trace, I found out that there is a problem with doFilter function in the OncePerRequestFilter class! However, when I put a break point there and the program never stop at that break point.

Could anyone give explanation about this!? And in general case, how should I use that stack case for debugging (read from bottom to top or from top to bottom)!

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
Toby D
  • 1,465
  • 1
  • 19
  • 31

4 Answers4

81

You should generally read from the top - so in this case, there's a NullPointerException at line 66 of UnixServerJobController, in the handleRequest method. That method was called by SimpleControllerHandlerAdapter.handle, which was called by DispatcherServlet.doDispatch etc.

However, in this particular case it's likely that the first frame of the stack trace is all you need. Look at line 66 of UnixServerJobController, work out what might be null, and act accordingly.

Note that sometimes one exception is wrapped in another (which may in turn be wrapped in another, etc). In this case you should look at each of the stack traces - often it's the "most nested" exception which gives the most useful information, as that's the root cause.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
58

Generally the exact reason for the Exception is at the first line of your Stack Trace, and for more information about the cause of that exception, you need to gradually move down, and the root cause can often be found somewhere near the bottom of the stack trace.

But in most cases, you can even get the cause of the exception from the first few lines..

So, in this case, your exception is at handleRequest method, and when you move downwards, those are the methods, which invoked your previous method (The one at above the current method in stack trace)

ljk
  • 488
  • 1
  • 5
  • 11
Rohit Jain
  • 209,639
  • 45
  • 409
  • 525
  • 11
    In enterprise java, the bottom of the call stack is often a library function, and not worthwhile investigating. – John Dvorak Oct 02 '12 at 09:58
  • 1
    @JanDvorak.. May be that it is not often required to investigate that, but it is the `root` cause right?? So, where I'm wrong in saying that?? – Rohit Jain Oct 02 '12 at 09:59
  • If you want to get blamed for the mistakes of all your employees, then yes, the library is at fault :-) – John Dvorak Oct 02 '12 at 10:00
  • @JanDvorak.. Ok. that I consider.. I've edited the post to say - `somewhere near bottom`.. Can it be justified in your case?? – Rohit Jain Oct 02 '12 at 10:01
  • @JanDvorak.. If my modified post looks OK, can you toggle your vote.. Or, I would like you to explain a little bit more, so that I can understand it better and be more clear.. – Rohit Jain Oct 02 '12 at 10:06
  • 5
    As you can see from the stack trace, there are nine stack frames from the library, and only the top frame is a user function (and likely to blame). This is often the case that the cause is near the top. – John Dvorak Oct 02 '12 at 10:07
  • 1
    "is near the bottom" is not true. "is often near the bottom" may be diputed. "can be near the bottom" is certainly true, but does not tell much. – John Dvorak Oct 02 '12 at 10:10
  • Here is also a very usefull link to understand how to read the stack trace from an exception: https://www.nurkiewicz.com/2011/09/logging-exceptions-root-cause-first.html – Elio Jun 25 '19 at 10:21
11

This tutorial might shed some light on your problem and help you understand things better.

As per your problem, you seem to have a Null Pointer Exception at line 66 of the Unix Server Job Controller class.

npinti
  • 51,780
  • 5
  • 72
  • 96
2

I found this tutorial is highly useful to me https://forums.bukkit.org/threads/how-to-read-stack-traces-and-troubleshoot-your-own-plugins-by-yourself.32457/

Toby D
  • 1,465
  • 1
  • 19
  • 31
  • 18
    This is basically a link-only answer, which is almost never a good idea. (It becomes utterly useless if the linked page is removed, for example.) You should *at least* quote the most important parts of the post. – Jon Skeet Jul 03 '13 at 05:46