Capture errors

Uncaught is automatic; caught is yours to report

At init(), Crossdeck installs global handlers for uncaught exceptions, unhandled promise rejections, and a wrap around fetch (plus XHR on web). So crashes report themselves — you don't lift a finger. One sensible boundary: HTTP capture fires only on 5xx and network failures; a 4xx is never auto-reported, because a bad request usually isn't your bug.

The gap the global handlers can't see is the error your own code catches. The moment you write try/catch, that error is invisible to them — handled, swallowed, gone. Reporting those is the one thing this lesson adds, and it's a single call.

captureError for exceptions, captureMessage for signals

Inside a catch, hand the error to Crossdeck — optionally with context, tags, and a level:

try {
  await chargeCard();
} catch (err) {
  Crossdeck.captureError(err, { context: { plan: "pro" }, tags: { flow: "checkout" } });
}

// for a non-exception signal — a deprecated path, a slow branch:
Crossdeck.captureMessage("entered legacy checkout path", "warning");

There are three levels — error, warning, info. If you're migrating from Sentry, its fatal, debug, and log are silently coerced to error, so existing code keeps working.

Attributed, enriched, and safe by default

A captured error doesn't travel alone. It carries the context that was set when it fired — your tags, named context blocks, the last 50 breadcrumbs, and the identity known at capture time. That last point is the one to remember: call identify() first, or the error is attributed to the anonymous ID and you lose the "which customer hit this?" answer.

Under the hood, errors ride the same durable queue as your analytics — persisted, retried, and rate-limited per fingerprint so one hot bug can't flood you. Sends are gated by consent.errors, and the call never throws, even if the SDK isn't initialised yet — so wrapping your code in capture calls can never itself become a source of crashes.

Crashes and caught errors, both in Issues

Throw an uncaught error and it appears in Issues on its own. Wrap a risky call in captureError and the handled failures show up too — each attributed to the user who hit it, with its context attached.