I want JavaScript error stack traces to be more helpful
Submitted by Patrick Brosset
Permalink https://webwewant.fyi/wants/eba5a436-0206-41ec-9967-34a7da515696/
This idea is currently being discussed.
When a JavaScript error is thrown, the stack trace I see in DevTools shows me where the error occurred — the chain of function calls that were active at that moment. But the real root cause of a bug is frequently not in that list. It lives earlier in the execution: in an argument that was passed incorrectly, a return value that was mishandled, or a call that happened several frames before the failure.
Today, tracking down the root cause means semi-randomly placing breakpoints or sprinkling console.log calls throughout the code until you get lucky. This is frustrating and time-consuming.
I want JavaScript engines to capture richer tracing information, especially when running in a developer/debug mode where performance trade-offs are acceptable. Specifically:
- Arguments and return values on the stack: Each frame in a stack trace should optionally include a serialized snapshot of the function's arguments and return value, so I can immediately see what data was flowing through the call chain when the error occurred.
- Previous call traces: Engines should retain a short history of recent call stacks — a rolling trace buffer — so that when an error is thrown, I can look back at what happened in the moments leading up to it. This is similar to what tracing debuggers already do, but integrated directly into the error report.
This would let me see not just where my program broke, but why it broke — dramatically speeding up debugging and reducing reliance on breakpoint-heavy workflows.
- Votes
- 0
What are votes for and how are they tallied?