How to read and understand the java stack trace? [duplicate]

Question

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)!

Answer 1

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.