In JavaScript, what is an Error object's `stack` property, when are its frames captured, and why is parsing it fragile?

## What the property is When you create an error, the engine records the chain of function calls that led to that point and exposes it as `err.stack`, a string. It is the single most useful field on an error for debugging, and the one most often misunderstood. ```js function inner() { return new Error('boom'); } function outer() { return inner(); } console.log(outer().stack); ``` In a V8 runtime this prints something shaped like: ``` Error: boom at inner (/app/a.js:1:26) at outer (/app/a.js:2:26) at Object.<anonymous> (/app/a.js:3:13) ``` ## It is captured at construction, not at throw This is the point interviewers actually probe. The frames are snapshotted when the `Error` object is built. Throwing it later, catching it, rethrowing it, or storing it in a module-level constant does not re-capture anything: ```js const preMade = new Error('boom'); // frames captured here function later() { throw preMade; } // this frame is NOT in the stack try { later(); } catch (e) { console.log(e.stack); } ``` The trace shows the top-level line where `preMade` was created, and `later` appears nowhere. Two practical consequences follow. Reusing a singleton error object across call sites produces a trace that points at the wrong place forever. And rethrowing a caught error with `throw e` deliberately preserves the *original* capture site — which is usually what you want, and is why rethrowing the same object beats constructing a fresh error that would point at the catch block. (In V8 the *formatting* of the string is lazy — the frames are held structurally and the text is built the first time `.stack` is read — but the frames themselves were fixed at construction. Lazy formatting changes when the cost is paid, not what is recorded.) ## It is not standardized ECMAScript defines `name` and `message` on `Error.prototype`; it does not define `stack`. There is a long-running proposal to standardize *something*, but today the property is a de-facto convention, and its exact text differs by engine: - V8 (Chrome, Node, Edge, Deno) starts with a `Name: message` header line, then indented `at ...` frames. - SpiderMonkey (Firefox) has no header line and uses a `functionName@file:line:column` shape. - JavaScriptCore (Safari) differs again. So `err.stack.split('\n')[1]` means different things in different browsers, and grouping errors in a tracker by a regex over frame text is a portability bug waiting to happen. If you need structured frames, use the tooling in your runtime rather than hand-rolled parsing, and keep the raw string as the fallback. The property is also writable in practice — code can assign to `err.stack`, and some libraries do. Never treat it as a trustworthy record of provenance for anything security-related. ## It is truncated In V8, `Error.stackTraceLimit` controls how many frames are captured; the default is **10**. Deep recursion or a long framework call chain therefore hands you a trace that stops mid-way with no marker that anything was elided. Raising it (`Error.stackTraceLimit = 50`, or `Infinity`) captures more, at a real cost: capturing frames is not free, and on a hot error path — a service that throws thousands of times a second — an unbounded limit is a measurable throughput regression. It is a knob for debugging sessions and for a temporary production investigation, not a set-and-forget value. ## Enumerability and serialization Like `message`, `stack` is non-enumerable, so `JSON.stringify(err)` yields `{}` and object spread drops it. Every logging pipeline needs an explicit error serializer that reads `name`, `message` and `stack` by name. This is the most common reason production logs contain a useless empty object where an error should be. ## How to use it well - Log the whole string; do not slice it to "keep logs tidy" — the frame you cut is the one you needed. - Construct errors at the point of failure so the capture site is the failure site. - Do not branch on stack contents. Branch on error type or on an explicit code property, both of which are stable and cheap to test. - Remember that the string is a snapshot of *your* frames only: asynchronous boundaries and minification both degrade it, and each needs its own remedy.