ActiveManage Docs ← Back to activemanage.co.uk

Capturing Stack Traces

Stack traces are the breadcrumbs that lead from a thrown exception back to the line of code that caused it — and through every caller in between. They're the single most useful piece of debugging information when something goes wrong.

Stack trace viewer showing exception class and message at the top, then numbered frames from innermost to outermost with file path, line number and function name; clickable frames open the source in the IDE

What's Captured

  • Exception class and message: the type of error and human-readable text.
  • Frame stack: the chain of function calls from where the error was thrown back up through the entry point.
  • For each frame: file path, line number, function name.
  • Optionally: function arguments at each frame, local variables.
  • Context: request URL, user ID, IP, request body summary.

When Traces Are Captured

  • Uncaught exceptions always produce a trace.
  • Caught exceptions can optionally call $AM->logException($e) to record without re-throwing.
  • Manual capture points: $AM->logTrace('reached suspicious branch') records a non-error trace.

Performance Cost

Capturing a stack trace is cheap — measured in microseconds. The expensive part is including arguments (next article). Standard stack-trace-only capture is essentially free.

Worked Examples

  • Null pointer in checkout: Trace shows the exception originated 3 frames deep in cart-helper.php, called from checkout.php, called from the controller. Bug is in cart-helper.
  • SQL error in API: Trace shows the bad query was built inside query-builder.php with caller-provided invalid filter. Adjust the input validation.
  • Performance regression: Manual trace at known slow point reveals the new caller path that bypassed the cache.
  • Cross-service issue: Stack trace plus request URL identifies the upstream consumer that's hitting a now-deprecated endpoint.