Stack trace
The list of function calls that led to a crash, so you can see exactly which line broke and what called it.
See it
What it is
When code throws, the runtime freezes the chain of function calls that were in flight and prints it: which function failed, who called it, who called that, all the way back to the entry point. Each line is a frame with a function name, file, and line number. Read it top down: the top frame is where it exploded, the frames below are how you got there.
Most of the frames are library and framework noise. The useful move is scanning down for the first line that points at a file you actually wrote. Languages differ in direction (Python prints the origin first and the failure last, JavaScript and Java print the failure first) and in wording, but 'Caused by' chains and 'nested exception' blocks all mean the same thing: an error was caught and rethrown, so keep reading down for the original one.
Gotcha: in production the trace often points at 'main.4f2a.js:1:88213', because your bundler minified everything into one line. Upload source maps to your error tracker so it can symbolicate the frames back to real file names. The other classic trap is async code: an error inside a callback or a detached promise can produce a trace that skips the code that scheduled it entirely.
Ask AI for it
Add a global error handler to this app that captures the full stack trace on every uncaught exception and unhandled promise rejection, attaches request context (route, user id, correlation id), and sends it to an error tracker instead of printing to stdout. Preserve the original error when rethrowing by passing the original as the 'cause' option so the root frame survives. Then wire source map upload into the build so the reported frames show real file names and line numbers, not minified bundle offsets.