Stack Trace Explainer

What this does and what it cannot do

The pasted text is scrubbed first. Anything shaped like a bearer token, a JSON web token, a basic auth header, a password= or api_key= pair, a connection string carrying a password, a cloud provider key, a private key block or an email address is replaced before a single line is parsed, and the panel above the trace says what was removed. That happens in the page, in your browser; the text never goes anywhere regardless. The patterns catch the obvious shapes and will miss a secret that looks like ordinary text, so read what you paste.

What this page sees is the text and nothing else. It has no access to your source, your dependency versions, your configuration or the state the process was in. So the ranked causes are informed guesses about where to look, not a diagnosis. The exception table holds the failure modes that actually produce each type in practice; the ranking moves a cause up when the wording of your message matches it. The frame that gets marked "start here" is chosen by path heuristics, and a project laid out unusually can fool them.

Why most of a trace is noise

A stack trace records the call stack at the moment the program gave up. Its length is mostly irrelevant: forty of fifty lines belong to a web framework, a servlet container or the language runtime, and they describe how the request travelled rather than what went wrong. The useful information sits in two places, the exception line at the top and the handful of frames carrying your own package or path. Marking those frames is the point of this page.

How a frame is classified

Java and .NET name packages, so a frame under java.*, javax.*, org.springframework.*, System.* or Microsoft.* is runtime or framework code. Node, Python, Go and PHP name paths, so node_modules, node:internal, site-packages, the Go module cache and vendor/ mark the same thing. Whatever is left is treated as yours. The topmost such frame is the one to open, because the stack is ordered innermost first and the innermost frame you control is where the wrong assumption lives.

Python prints its traceback the other way up

Java, Node, .NET, Go and PHP print the failure first and the entry point last. Python prints the oldest call first, so the failing line is at the bottom of the output and the exception message is the very last line. Mixing that up is one of the most common ways people misread a Python traceback, and this page reorders the frames so that every language reads the same way here.

Caused by chains carry the real story

When one exception is thrown while another is being handled, the runtime wraps it. Java prints a Caused by: block, .NET uses ---> inside the message, Python says either "The above exception was the direct cause" or "During handling of the above exception". The outermost exception is usually the least informative — something generic like "could not execute statement" — and the deepest one names the constraint, the socket or the null that actually failed. Read from the bottom of the chain outwards, and fix there.

Where this page stops

It does not change code, run anything or look at your repository. A trace tells you where a program stopped, not why the value that broke it got there. That part is yours: open the file it points at, work out which assumption that line makes about its input, and find the path that makes the assumption false.