Call Stack (Stack Trace)

1. Introduction

Stack trace (call stack) — a list of methods that were invoked in your program up to the moment an error (exception) occurred. When an exception occurs, Java automatically prints the stack trace to the screen. It is like “footprints in the snow”: you can see the steps the program took to reach the error.

Analogy:
Imagine you are walking through a maze and suddenly run into a wall. The stack trace is a map showing which corridors you took before getting lost.

What does a stack trace look like?

When an error occurs in a program, Java prints a message like this:

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Main.divide(Main.java:10)
    at Main.main(Main.java:5)

What does this mean?

• Exception in thread "main" — the thread where the error occurred (usually "main").
• java.lang.ArithmeticException: / by zero — the exception type and its message.
• at Main.divide(Main.java:10) — the divide method in the Main class, line 10.
• at Main.main(Main.java:5) — the main method in the Main class, line 5.

Each at ... line is a step in the call stack. The very top line is where the error occurred. Below are the methods that called that method, and so on back to the start of the program.

2. How to read a stack trace?

Step 1. Find the exception type and message

The first line always contains the error type and its description:

java.lang.ArithmeticException: / by zero

That already tells you the error is related to division by zero.

Step 2. Look at the first “at ...” line

This is where the error actually occurred:

at Main.divide(Main.java:10)

So the error happened in the divide method of the Main class on line 10.

Step 3. Work your way up the stack

The next line shows who called that method:

at Main.main(Main.java:5)

So the main method called divide, and the error “bubbled up”. Line number is 5.

Step 4. Look for your own classes

In a long stack trace, you will often see system methods (for example, from the java.util and java.io packages).
Your classes are usually closer to the top of the list. Look at class and file names — look for yours!

3. Example: dissecting a real stack trace

Code:

public class Main 
{
    public static void main(String[] args) 
    {
        int result = divide(10, 0);
        System.out.println("Result: " + result);
    }

    public static int divide(int a, int b) 
    {
        return a / b;
    }
}

Error:

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Main.divide(Main.java:8)
    at Main.main(Main.java:3)

Let’s break it down:

• Error: division by zero (ArithmeticException).
• Occurred in the divide method on line 8.
• Called from the main method on line 3.

What to do?
Open the Main.java file, go to line 8 — you’ll find the division by zero. Fix it!

4. Stack trace with multiple methods

Code:

public class Main 
{
    public static void main(String[] args) 
    {
        process();
    }

    public static void process() 
    {
        calculate();
    }

    public static void calculate() 
    {
        int[] arr = {1, 2, 3};
        System.out.println(arr[10]); // Error!
    }
}

Error:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 10 out of bounds for length 3
    at Main.calculate(Main.java:11)
    at Main.process(Main.java:7)
    at Main.main(Main.java:3)

Let’s break it down:

• Error: array index out of bounds (ArrayIndexOutOfBoundsException).
• Occurred in calculate (line 11).
• Called from process (line 7).
• Called from main (line 3).

Conclusion:
The stack trace shows the entire path by which the program reached the error.

5. Common mistakes when working with a stack trace

Error #1: Ignoring the stack trace.
Beginners often just look at the “red error” and don’t read the call stack. Don’t do that! Stack trace is a hint about where to look for the bug.

Error #2: Confusing the error line with the line where it happened.
Important: the first line is the error type, and the error location is in the first at ... line.

Error #3: Looking for the bug in system classes.
If you see lines like at java.base/java.util.Scanner.nextInt(Scanner.java:123), don’t rush to dive into Java’s sources. Look at who called that method in your code.

Error #4: Not using line numbers.
The line number is your best friend. Open the file, find the needed line — and you’ll see the error.

Error #5: Not realizing that a stack trace is a “path”.
A stack trace shows how the program reached the error. Sometimes the bug isn’t in the very top line but in how you called the method.