Use captureException SDK methods in error tracking examples#152
Merged
Conversation
Several examples were emitting `$exception` events through the generic `capture` method with hand-built property bags. Switch each example to the SDK's first-class exception capture API so PostHog receives proper exception metadata (correct `$exception_list` shape, fingerprinting, etc). - Angular, Expo, React Native: use `posthog.captureException(error, ...)` - Ruby: use `posthog.capture_exception(e, distinct_id)`, bump Gemfile to `~> 3.3` (first version with `capture_exception`) - Laravel: delegate `PostHogService::captureException` to `PostHog::captureException` (the previous wrapper was building props without the `$` prefix so PostHog never parsed them as exception fields); bump composer to `^4.2` and update lock to 4.2.0 - Update each example README snippet to match Generated-By: PostHog Code Task-Id: 6c6bee2c-5a44-44bd-8654-79904e690605
Member
|
i think @PostHog/team-error-tracking would know better |
hpouillot
approved these changes
May 27, 2026
| }, | ||
| ], | ||
| posthog.captureException(error, { | ||
| $exception_source: 'react-native', |
There was a problem hiding this comment.
$exception_source is not processed at ingestion, we only recognize $exception_fingerprint (for custom grouping) or $exception_level
There was a problem hiding this comment.
++ I was about to comment this, I think we should get rid of those $exception_source - it's "legacy", we have a plural version now that gets computed from the frames, i.e.:
Collaborator
Author
There was a problem hiding this comment.
I'll remove this for now. I don't think this should be as a part of the basic integration skill anyway.
cat-ph
approved these changes
May 27, 2026
Per review feedback: `$exception_source` is not processed at ingestion (only `$exception_fingerprint` and `$exception_level` are). Sources are computed from stack frames now. Remove it from the Expo and React Native profile screens and from the React Native README snippet. Generated-By: PostHog Code Task-Id: 6c6bee2c-5a44-44bd-8654-79904e690605
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Manoel flagged in Slack that some of our examples were capturing
$exceptionevents through the genericcapturemethod with hand-built property bags. This PR switches each example to the SDK's first-class exception capture API so PostHog receives proper exception metadata (correct$exception_listshape, fingerprinting, etc).Changes per example
posthog-js): useposthog.captureException(error)posthog-react-native@4): useposthog.captureException(error, additionalProperties)posthog-ruby): useposthog.capture_exception(e, distinct_id); bumpGemfileto~> 3.3(first 3.x to shipcapture_exception)posthog-php): delegatePostHogService::captureExceptiontoPostHog::captureException. The previous wrapper built properties without the$prefix (exception_type,exception_message, ...) so PostHog never parsed them as exception fields. Bumpscomposer.jsonto^4.2and updatescomposer.lockto 4.2.0 (first 4.x withPostHog::captureException).Test plan
ng buildsucceeds for the Angular example with the new codetsc --noEmit -p .on Expo example reports no new errors (only pre-existing unrelated errors)tsc --noEmit -p .on React Native example reports no new errors inProfileScreen.tsx$exceptionevents show up in PostHog Error Tracking with parsed stack framesTested these locally to make sure they work
Created with PostHog Code