debugging java stack-trace

What is a stack trace, and how can I use it to debug my application errors?


Sometimes when I run my application it gives me an error that looks like:

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(
        at com.example.myproject.Author.getBookTitles(
        at com.example.myproject.Bootstrap.main(

People have referred to this as a “stack trace”. What is a stack trace? What can it tell me about the error that’s happening in my program?

About this question – quite often I see a question come through where a novice programmer is “getting an error”, and they simply paste their stack trace and some random block of code without understanding what the stack trace is or how they can use it. This question is intended as a reference for novice programmers who might need help understanding the value of a stack trace.


  • 32

    Also, if a stacktrace line does not contain the filename and a line number, the class for that line was not compiled with debug information.

    Mar 10, 2011 at 21:11


In simple terms, a stack trace is a list of the method calls that the application was in the middle of when an Exception was thrown.

Simple Example

With the example given in the question, we can determine exactly where the exception was thrown in the application. Let’s have a look at the stack trace:

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(
        at com.example.myproject.Author.getBookTitles(
        at com.example.myproject.Bootstrap.main(

This is a very simple stack trace. If we start at the beginning of the list of “at …”, we can tell where our error happened. What we’re looking for is the topmost method call that is part of our application. In this case, it’s:

at com.example.myproject.Book.getTitle(

To debug this, we can open up and look at line 16, which is:

15   public String getTitle() {
16      System.out.println(title.toString());
17      return title;
18   }

This would indicate that something (probably title) is null in the above code.

Example with a chain of exceptions

Sometimes applications will catch an Exception and re-throw it as the cause of another Exception. This typically looks like:

34   public void getBookIds(int id) {
35      try {
36         book.getId(id);    // this method it throws a NullPointerException on line 22
37      } catch (NullPointerException e) {
38         throw new IllegalStateException("A book has a null property", e)
39      }
40   }

This might give you a stack trace that looks like:

Exception in thread "main" java.lang.IllegalStateException: A book has a null property
        at com.example.myproject.Author.getBookIds(
        at com.example.myproject.Bootstrap.main(
Caused by: java.lang.NullPointerException
        at com.example.myproject.Book.getId(
        at com.example.myproject.Author.getBookIds(
        ... 1 more

What’s different about this one is the “Caused by”. Sometimes exceptions will have multiple “Caused by” sections. For these, you typically want to find the “root cause”, which will be one of the lowest “Caused by” sections in the stack trace. In our case, it’s:

Caused by: java.lang.NullPointerException <-- root cause
        at com.example.myproject.Book.getId( <-- important line

Again, with this exception we’d want to look at line 22 of to see what might cause the NullPointerException here.

More daunting example with library code

Usually stack traces are much more complex than the two examples above. Here’s an example (it’s a long one, but demonstrates several levels of chained exceptions):

javax.servlet.ServletException: Something bad happened
    at com.example.myproject.OpenSessionInViewFilter.doFilter(
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(
    at com.example.myproject.ExceptionHandlerFilter.doFilter(
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(
    at com.example.myproject.OutputBufferFilter.doFilter(
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(
    at org.mortbay.jetty.servlet.ServletHandler.handle(
    at org.mortbay.jetty.servlet.SessionHandler.handle(
    at org.mortbay.jetty.handler.ContextHandler.handle(
    at org.mortbay.jetty.webapp.WebAppContext.handle(
    at org.mortbay.jetty.handler.HandlerWrapper.handle(
    at org.mortbay.jetty.Server.handle(
    at org.mortbay.jetty.HttpConnection.handleRequest(
    at org.mortbay.jetty.HttpConnection$RequestHandler.content(
    at org.mortbay.jetty.HttpParser.parseNext(
    at org.mortbay.jetty.HttpParser.parseAvailable(
    at org.mortbay.jetty.HttpConnection.handle(
    at org.mortbay.thread.QueuedThreadPool$
Caused by: com.example.myproject.MyProjectServletException
    at com.example.myproject.MyServlet.doPost(
    at javax.servlet.http.HttpServlet.service(
    at javax.servlet.http.HttpServlet.service(
    at org.mortbay.jetty.servlet.ServletHolder.handle(
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(
    at com.example.myproject.OpenSessionInViewFilter.doFilter(
    ... 27 more
Caused by: org.hibernate.exception.ConstraintViolationException: could not insert: [com.example.myproject.MyEntity]
    at org.hibernate.exception.SQLStateConverter.convert(
    at org.hibernate.exception.JDBCExceptionHelper.convert(
    at org.hibernate.persister.entity.AbstractEntityPersister.insert(
    at org.hibernate.persister.entity.AbstractEntityPersister.insert(
    at org.hibernate.action.EntityIdentityInsertAction.execute(
    at org.hibernate.engine.ActionQueue.execute(
    at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(
    at org.hibernate.event.def.AbstractSaveEventListener.performSave(
    at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(
    at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(
    at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(
    at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(
    at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(
    at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(
    at org.hibernate.impl.SessionImpl.fireSave(
    at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(
    at $ Source)
    at <-- relevant call (see notes below)
    at com.example.myproject.MyServlet.doPost(
    ... 32 more
Caused by: java.sql.SQLException: Violation of unique constraint MY_ENTITY_UK_1: duplicate value(s) for column(s) MY_COLUMN in statement [...]
    at org.hsqldb.jdbc.Util.throwError(Unknown Source)
    at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)
    at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(
    ... 54 more

In this example, there’s a lot more. What we’re mostly concerned about is looking for methods that are from our code, which would be anything in the com.example.myproject package. From the second example (above), we’d first want to look down for the root cause, which is:

Caused by: java.sql.SQLException

However, all the method calls under that are library code. So we’ll move up to the “Caused by” above it, and in that “Caused by” block, look for the first method call originating from our code, which is:


Like in previous examples, we should look at on line 59, because that’s where this error originated (this one’s a bit obvious what went wrong, since the SQLException states the error, but the debugging procedure is what we’re after).


  • 4

    @RobHruska – Very well explained. +1. Do you know of any parsers that take the exception trace as a string and provide useful methods to analyze stacktrace? – like getLastCausedBy() or getCausedByForMyAppCode(“com.example.myproject”)

    Nov 9, 2014 at 6:33

  • 1

    @AndyDufresne – I haven’t come across any, but then again I haven’t really looked, either.

    Nov 10, 2014 at 12:57

  • 2

    Suggested improvement: explain the the first line of a stack trace which starts with Exception in thread "main" in your first example. I think It would be especially helpful to explain that this line is often accompanied by a message, such as the value of a variable, that can help diagnose the problem. I attempted to make an edit myself, but I’m struggling to fit these ideas into the existing structure of your answer.

    Jun 11, 2015 at 14:31

  • 5

    Also java 1.7 added “Suppressed: ” – which lists suppressed exceptions stack traces before displaying “Caused by:” for this exception. It’s automatically used by try-with-resource construct:… and contains exceptions if any that was thrown during the resource(s) closure.

    – dhblah

    Jul 1, 2015 at 13:48

  • 1

    There is a JEP that aims to further improve the comprehensibility of especially NPEs by providing details like “Cannot write field ‘nullInstanceField’ because ‘this.nullInstanceField’ is null.”

    Jun 5, 2019 at 6:33


What is a Stacktrace?

A stacktrace is a very helpful debugging tool. It shows the call stack (meaning, the stack of functions that were called up to that point) at the time an uncaught exception was thrown (or the time the stacktrace was generated manually). This is very useful because it doesn’t only show you where the error happened, but also how the program ended up in that place of the code.
This leads over to the next question:

What is an Exception?

An Exception is what the runtime environment uses to tell you that an error occurred. Popular examples are NullPointerException, IndexOutOfBoundsException or ArithmeticException. Each of these are caused when you try to do something that is not possible. For example, a NullPointerException will be thrown when you try to dereference a Null-object:

Object a = null;
a.toString();                 //this line throws a NullPointerException

Object[] b = new Object[5];
System.out.println(b[10]);    //this line throws an IndexOutOfBoundsException,
                              //because b is only 5 elements long
int ia = 5;
int ib = 0;
ia = ia/ib;                   //this line throws an  ArithmeticException with the 
                              //message "/ by 0", because you are trying to
                              //divide by 0, which is not possible.

How should I deal with Stacktraces/Exceptions?

At first, find out what is causing the Exception. Try googling the name of the exception to find out what the cause of that exception is. Most of the time it will be caused by incorrect code. In the given examples above, all of the exceptions are caused by incorrect code. So for the NullPointerException example you could make sure that a is never null at that time. You could, for example, initialise a or include a check like this one:

if (a!=null) {

This way, the offending line is not executed if a==null. Same goes for the other examples.

Sometimes you can’t make sure that you don’t get an exception. For example, if you are using a network connection in your program, you cannot stop the computer from loosing it’s internet connection (e.g. you can’t stop the user from disconnecting the computer’s network connection). In this case the network library will probably throw an exception. Now you should catch the exception and handle it. This means, in the example with the network connection, you should try to reopen the connection or notify the user or something like that. Also, whenever you use catch, always catch only the exception you want to catch, do not use broad catch statements like catch (Exception e) that would catch all exceptions. This is very important, because otherwise you might accidentally catch the wrong exception and react in the wrong way.

try {
    Socket x = new Socket("", 6789);
} catch (IOException e) {
    System.err.println("Connection could not be established, please try again later!")

Why should I not use catch (Exception e)?

Let’s use a small example to show why you should not just catch all exceptions:

int mult(Integer a,Integer b) {
    try {
        int result = a/b
        return result;
    } catch (Exception e) {
        System.err.println("Error: Division by zero!");
        return 0;

What this code is trying to do is to catch the ArithmeticException caused by a possible division by 0. But it also catches a possible NullPointerException that is thrown if a or b are null. This means, you might get a NullPointerException but you’ll treat it as an ArithmeticException and probably do the wrong thing. In the best case you still miss that there was a NullPointerException. Stuff like that makes debugging much harder, so don’t do that.


  1. Figure out what is the cause of the exception and fix it, so that it doesn’t throw the exception at all.
  2. If 1. is not possible, catch the specific exception and handle it.
    • Never just add a try/catch and then just ignore the exception! Don’t do that!
    • Never use catch (Exception e), always catch specific Exceptions. That will save you a lot of headaches.


  • 1

    nice explanation for why we should avoid bug masking

    Dec 20, 2016 at 10:07

  • 4

    I am posting this answer so the topmost answer (when sorted by activity) is not one that is just plain wrong I have no idea of which one you are talking about since this probably ahve changed by now. But the accepted answer is definitly more interresting 😉

    – AxelH

    Feb 6, 2017 at 14:15

  • 2

    The one I meant has been deleted by now, as far as I know. It basically said “just put a try{} catch(Exception e){} and ignore all errors”. The accepted answer is a lot older than my answer so I was aiming to give a little bit of a different view on the matter. I don’t think it helps anyone to just copy someone else’s answer or to cover what other people already covered well.

    – Dakkaron

    Feb 6, 2017 at 16:43

  • It’s misleading to say “Do not catch exception”, that’s only one use case. Your example is great, but how about where you are at the top of your thread loop (inside run)? You should ALWAYS catch exception (or maybe Throwable) there and log it so that it doesn’t invisibly vanish (Exceptions thrown from run generally aren’t logged correctly unless you’ve set up your thread/logger to do so).

    – Bill K

    Mar 7, 2017 at 17:22

  • 2

    I didn’t include this special case since it only matters with multithreading. In single threading a leaked exception kills the program and is logged visibly. If someone does not know how to handle exceptions properly, they usually don’t know how to use multithreading yet either.

    – Dakkaron

    Mar 8, 2017 at 14:17


To add on to what Rob has mentioned. Setting break points in your application allows for the step-by-step processing of the stack. This enables the developer to use the debugger to see at what exact point the method is doing something that was unanticipated.

Since Rob has used the NullPointerException (NPE) to illustrate something common, we can help to remove this issue in the following manner:

if we have a method that takes parameters such as: void (String firstName)

In our code we would want to evaluate that firstName contains a value, we would do this like so: if(firstName == null || firstName.equals("")) return;

The above prevents us from using firstName as an unsafe parameter. Therefore by doing null checks before processing we can help to ensure that our code will run properly. To expand on an example that utilizes an object with methods we can look here:

if(dog == null || dog.firstName == null) return;

The above is the proper order to check for nulls, we start with the base object, dog in this case, and then begin walking down the tree of possibilities to make sure everything is valid before processing. If the order were reversed a NPE could potentially be thrown and our program would crash.


  • Agreed. This approach could be used to find out which reference in a statement is null when a NullPointerException is being examined, for example.

    Oct 21, 2010 at 15:07

  • 18

    When dealing with String, if you want to use equals method I think it´s better to use the constant in the left side of the comparation, like this: Instead of: if(firstName == null || firstName.equals(“”)) return; I always use: if((“”).equals(firstName)) This prevents the Nullpointer exception

    – Torres

    Oct 26, 2010 at 6:23

  • Splendid explanation. Really adds value.

    Sep 23, 2021 at 10:55