Events without stack traces: get the frames back
Errors arrive in AllStak as bare messages with no frames to debug from. The cause is almost always in how the error was thrown or captured.
What this looks like
The event shows a message — "checkout failed", "undefined is not a function" — but no stack frames underneath it. You cannot see which file, function, or line produced the error, which makes grouping coarse and debugging slow.
A stack trace exists only when an actual exception object travels to the SDK. Messages logged as strings, values thrown that are not Error objects, or captures that pass text instead of the exception all arrive trace-less — the SDK cannot reconstruct frames it never received.
Common root causes
Throwing non-Error values in JavaScript
throw 'payment failed' or throw { code: 500 } carries no stack. Only Error instances (and subclasses) capture the call stack at construction time.
Capturing messages instead of exceptions
captureMessage('it broke') is for informational events and has no trace by design. Inside a catch block, pass the caught exception itself to captureException.
Capture gates disabled
SDK integrations with exception-capture gates (e.g. allstak.capture-exceptions in the Spring Boot starter) stop attaching automatic exception capture when turned off, leaving only whatever you log manually.
Minified browser frames without source maps
In browser apps the trace may exist but be unreadable — one minified line with mangled names. That is a source-map problem, not a capture problem; see the source maps troubleshooting page.
Step-by-step diagnosis
Find where the trace is lost: at the throw site, the capture call, or the rendering.
- 1
Inspect how the error is thrown
Find the code path that produced the trace-less event. In JavaScript, replace throw 'msg' and thrown plain objects with throw new Error('msg') — only Error instances carry a stack.
- 2
Pass the exception object to captureException
In catch blocks, call captureException(error) with the caught object — not captureMessage with a string built from it. The SDK extracts frames from the exception itself.
- 3
Check the SDK's capture gates
Review your SDK configuration against its setup guide: exception-capture options default to on (e.g. allstak.capture-exceptions=true in Spring Boot, attachErrorHandler in Vue) — confirm nothing disabled them.
- 4
Distinguish unreadable from missing
If browser events show one long minified frame rather than no frames, the trace was captured fine — you need source maps uploaded for the event's release. Follow the source maps troubleshooting page for that path.
- 5
Throw a controlled test error
Add a temporary endpoint or button that throws new Error('allstak trace test') through the same code path, and confirm the event arrives with full frames. That isolates capture from your application logic.
Prevent it from recurring
- Adopt a lint rule (e.g. no-throw-literal) so only Error objects are ever thrown.
- Standardize on captureException for failures and captureMessage only for informational events.
- Keep exception-capture gates at their default (enabled) unless you have a documented reason.
- For browser apps, upload source maps per release so captured traces stay readable.
Still stuck?
If real Error objects reach captureException and events still arrive trace-less, email [email protected] with your SDK name and version, a code snippet of the capture site, and a link to one affected event — language-specific capture behavior is documented in each SDK setup guide.
Frequently asked questions
Why does captureMessage never include a stack trace?
By design — captureMessage records an informational event, not an exception. When you have an exception object, pass it to captureException so its frames travel with the event.
I see one minified frame — is that a missing trace?
No, that is a captured but unreadable trace. Upload source maps for the exact release the SDK sends and new events will resolve to original files and lines.
Do async errors lose their stack traces?
An Error object created inside async code still carries the stack from where it was constructed. Traces get lost when code converts the error to a string (e.g. logging error.message) before capturing — always pass the object itself.
Debug from the exact line
Capture real exceptions with full frames, resolve them with source maps, and group them per release — all in one platform. Start free.