Improve Crashes.trackError for Swift based errors

[GyroJoe]

Is your feature request related to a problem? Please describe. By default, Crashes.trackError omits key information from errors reported from Swift.

Since Swift Errors are being implicitly converted to NSError, their userinfo payload is empty. It is common practice to implement Error using associated value enums. These associated values are lost when sent through trackError, losing key information.

Describe the solution you'd like Detect converted Swift Errors and utilize the error description directly for the message field instead.

This can be detected via the internal implementation Swift uses to handle conversion:

(lldb) po type(of: (error as NSError))
__SwiftNativeNSError

Describe alternatives you've considered For now, I've decided to wrap handled Errors in NSError myself before reporting them to AppCenter:

let convertedError = error as NSError
let wrappedError = NSError(domain: convertedError.domain, code: convertedError.code, userInfo: ["details": "\(error)"])

Another workaround is to reflect the error using Mirror and extract the associated values directly, then pass them as properties when tracking.

Additional context Xcode 13, iOS 15 https://github.com/apple/swift-evolution/blob/main/proposals/0112-nserror-bridging.md

[AnastasiaKubova]

Hello! Thanks for getting in touch with us! We will discuss it with a team.

[AnatolyPristensky]

Hello @GyroJoe, We are marked it as a feature request and created an item on our dashboard. We will update this conversation once finished.

[AnastasiaKubova]

Hi, @GyroJoe! I'm looking at this feature. We are going to add an overloaded constructor to MSACExceptionModel something like this:

- (instancetype)initWithType:(NSString *)domain
                        code:(NSInteger *)code
                    userInfo:(NSDictionary<NSErrorUserInfoKey, id>*)userInfo 

Will this API resolve your issue?

[GyroJoe]

@AnastasiaKubova while this would enable the workaround I mentioned above (really, it just eliminates the NSError construction), it doesn't exactly provide a clean and consistent way to reporting Swift errors.

Additionally, it doesn't prevent making the mistake I made initially - passing in a Swift Error to trackError loses most of the interesting information.

Given the prevalence and popularity of Swift, it would be good for the SDK to have an opinion about how such errors are reported (especially if we want to build tooling on the portal side).

Something like:

- (instancetype)initWithType:(NSString *)type
                     message:(NSString *)message 

Then in Swift:

extension MSACExceptionModel {
  convenience init(_ error: Error) {
    self.init(type: "\(type(of: error)", message: "\(error)")
  }
}

Ideally then unproject Crashes.trackError from Swift and build a native Swift method for of that.

Side note: The NSError code should really be getting reported too in Objective-C cases.

[DmitriyKirakosyan]

Hi @GyroJoe , thank you for the feedback. I agree that the feature should support tracking Swift Error natively. However, until the feature is implemented, as a workaround you can use properties or trackException API to pass the information manually taken from Error object. In such case there is no need to add additional workaround such as Anastasia proposed above.

We will keep this thread updated once there is any updates on this feature.

Please feel free to open a PR if you have a solution and time. Any contribution is always welcome!

[shanepadgett]

Is there any update on this? This appears to be causing issues with grouping errors correctly.

Edit for context: This is what our groups look like compared to the image in your docs. You will notice we do not get the groups based on this line from your docs: "For each crash and error group, App Center displays the line of code that failed, the class or method name, file name, line number, crash, or error type and message for you to better understand these groups at a glance."

Ours: The docs

Even converting our errors to NSError isnt helping with the grouping problem. This is a major issue for us because many of our errors arent getting grouped at all and are instead one offs even though they are the same error.

[radekwilczak]

I'm experiences the same issues as @shanepadgett

[DmitriyKirakosyan]

As we do not have plans to fix this bug in the next year, I'm closing the issue. However, contributions are still welcome.