How to Read a Stack Trace: Exception Types, Frames and Call Chains

A stack trace is recorded at the exact moment an exception unwinds, so it is the single most direct evidence a failure ships with. The useful reading order is: identify the exception type and message, then find the first frame written by your own code, and work outward from there.

Exception banner

The first line(s): the exception type and its human-readable message — for example NullPointerException: Cannot invoke "String.length()" because "s" is null.

Frame

One entry in the trace: a function name, a file, and a line number. The topmost frame is where the throw happened.

Origin frame

The first frame that lives in the application's own code rather than in a framework, library or runtime internals.

Call chain

The simplified, deduplicated list of functions that were active when the failure occurred — the readable version of the trace.

JavaScript / Node (V8)

A V8 trace lists frames as 'at fn (file:line)' in reverse call order, with the deepest call printed first. Internal runtime frames (node:internal/…) are marked as such so you can skip them. The exception type and message are the banner line at the top.

TypeError: Cannot read properties of undefined (reading 'name')
    at parseUser (src/api/parse.js:12)
    at handler (src/api/handler.js:8)
    at node:internal/process/task_queues:97:5

Java and JVM languages

Java traces start with an exception banner — often 'Exception in thread "main" java.lang…' — and list 'at' frames with fully qualified class names, so package ambiguity is rare. The trailing 'at App.main(App.java:12)' is where the throw began.

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "user" is null
    at com.example.ApiClient.fetch(ApiClient.java:120)
    at com.example.App.main(App.java:12)

Python

Python prints 'Traceback (most recent call last)' first, then File and line entries in call order (oldest to newest), and finally the exception type and message on its own line. Read the last File entry for the origin.

Traceback (most recent call last):
  File "/app/main.py", line 20, in <module>
    fetch_orders(api)
  File "/app/client.py", line 44, in fetch_orders
    return response.json()["orders"]
KeyError: 'orders'

Go

Go panics report panic: <runtime error> plus a goroutine header, and frames that reverse read cleanly: 'file.go:line +0x48 funcName(...)'. The first application frame after the goroutine header is your origin.

panic: runtime error: index out of range [3] with length 3

goroutine 1 [running]:
main.sumValues(0xc000108008, 0x3, 0x0, 0x0)
    /app/main.go:21 +0x7d
main.main()
    /app/main.go:9 +0x39

Read it in this order

1. Exception type and message: what actually went wrong, in one line.
2. The origin frame: the first frame that is your code, not node:internal, a framework or stdlib.
3. The frames above it identify the immediate caller; everything below is context.
4. Cross-check the failing input — the payload, headers or argument at that line — to turn the where into a why.

Try it

Paste a Java, JavaScript/Node, Python or Go trace into the Stack Trace Reader for automatic language detection, the exception type and message, the origin location, and a clean call chain. Pair it with the Error Workspace to correlate the trace with logs and the failing request.