Is there a way to make a Kotlin class implement th...

# multiplatform

[ribesg]

Is there a way to make a Kotlin class implement the Swift Error protocol in the ios part of my MPP project? NOT NSError

[svyatoslav.scherbina]

No.

[ribesg]

That’s what I thought, thanks for the confirmation. I have a hard time with the “no inheritance under an ObjC/Swift class” but I’ll find a way

[svyatoslav.scherbina]

I have a hard time with the “no inheritance under an ObjC/Swift class”

What do you mean?

[ribesg]

We’re making a logging mpp library which passes errors to Bugsnag through their Android & iOS clients.
I would like to have a BugsnagError class which would be the super class of all our errors and in which we could add metadata to appear on the Bugsnag interface.
It’s not possible easily because the iOS BugsnagError class cannot both be open and extend NSError. I can have it embed a NSError, but then it cannot be thrown from Swift because it does not implement the Error protocol.

[ribesg]

So right now I don’t think I have any other choice than have a extension BugsnagError: Error {} in the app using the lib...

[svyatoslav.scherbina]

You can wrap it to NSError instead.

[ribesg]

What do you mean ?

[svyatoslav.scherbina]

NSError can contain arbitrary data in userInfo dictionary. So you can throw NSError containing BugsnagError instance.

[ribesg]

I suppose that’s possible but userInfo is final and can’t be modified after the NSError is created. That prevents me from having a nice feature: adding metadata to an error after it has been created. Typically, I would add call-site information to an error returned by a webservice implementation before sending it to the logger. I don’t think we can work without that feature... I could wrap an error in another one every time I add data to it but then the code retrieving this data before sending it to bugsnag needs to become recursive and take duplicates into account... It makes a lot of things much harder

[svyatoslav.scherbina]

If BugsnagError was an Error, you would throw it.
It is not, so you can
* Throw NSError(userInfo: { "BugsnagError" : bugsnagError }) instead of bugsnagError
* Check that NSError has "BugsnagError" key instead of checking that error is BugsnagError
* Modify NSError.userInfo["BugsnagError"] object instead of modifying a caught error directly.

How can this make some code recursive? You can handle special NSError the same way you’d handle BugsnagError.

[ribesg]

You can modify NSError.userInfo["BugsnagError"]? I thought userInfo was a val

[svyatoslav.scherbina]

You can modify contents of NSError.userInfo["BugsnagError"], i.e. the object from userInfo.

[ribesg]

Oh, you mean that I could modify the BugsnagError instance, like calling methods on it etc, but not replace it

[svyatoslav.scherbina]

Yes. Alternatively you can throw new NSError instance with new BugsnagError inside. What I'm trying to say is that wrapping to NSError doesn't affect the operations available.