getsentry
Set synthetic field
The exception interface of the event payload defines a field synthetic, which doesn't exist in the SDK. This messes up grouping and should be added to the SDK. Since this has an impact on grouping, we have to bump a major for this.
this field should also be set to true whenever there's a stack trace, eg, segfault etc
greetings. in which cases do you want to set the field? I believe setting it in all cases is wrong.
I can't remember why I created this issue. If you, @untitaker, tell me we shouldn't use the field, I'm happy to close the issue.
Ah right. So we have two classes of exceptions in cocoa as far as I remember:
- the ones where the current thread's stacktrace is reported as exception stack (nserror?)
- genuine exceptions that actually hold a stacktrace produced from the exception bubbling up (nsexception?)
number (1) is the case where I believe we should set synthetic
we currently detect nserror on the server and set synthetic ourselves, but I believe the SDKs should set this property themselves, because this approach of doing a bunch of pattern-matching on the server doesn't scale with amount of platforms
I can't remember why I created this issue. If you, @untitaker, tell me we shouldn't use the field, I'm happy to close the issue.
This issue came up after talking to @mitsuhiko
Native events should set the synthetic field when captured by signal handlers.
The reason is described in the docs.
Setting synthetic=true for NSErrors breaks grouping by NSErrors domain and code. @untitaker, where on the server do you think you set synthetic=true for NSError?
According to the develop docs
Sentry will then try to use other information (top in-app frame function) rather than exception type and value in the UI for the primary event display.
We definitely don't want this for NSError. We want domain and code for primary event display. I currently can't think of any events where we would have to set synthetic=true. Maybe MetricKit events could use that field.
@mitsuhiko @danielkhan
I think we can close this. NSError is indeed not a synthetic exception, and the server does not detect it as synthetic exception.
@untitaker, thanks for the update. I'm going to add the synthetic, though, and I'm going to revisit if there are any other events for which we maybe should set this.
This item came from @mitsuhiko and it was not related to NSError, I don't remember exactly which type of exceptions in Cocoa should be marked as synthetic tho.
We didn't find any places to set the synthetic field in the SDK. MetricKit events will use the synthetic field. According to @mitsuhiko, grouping has room for improvement as we receive complaints about it through customer support regularly, which is unrelated to this issue.