https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
r

ribesg

02/22/2019, 9:24 AM
Is there a way to make a Kotlin class implement the Swift
Error
protocol in the ios part of my MPP project? NOT
NSError
s

svyatoslav.scherbina

02/22/2019, 9:33 AM
No.
r

ribesg

02/22/2019, 10:17 AM
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
s

svyatoslav.scherbina

02/22/2019, 11:48 AM
I have a hard time with the “no inheritance under an ObjC/Swift class”
What do you mean?
r

ribesg

02/22/2019, 12:50 PM
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.
So right now I don’t think I have any other choice than have a
extension BugsnagError: Error {}
in the app using the lib...
s

svyatoslav.scherbina

02/22/2019, 1:36 PM
You can wrap it to
NSError
instead.
r

ribesg

02/22/2019, 2:01 PM
What do you mean ?
s

svyatoslav.scherbina

02/22/2019, 2:14 PM
NSError
can contain arbitrary data in
userInfo
dictionary. So you can throw
NSError
containing
BugsnagError
instance.
r

ribesg

02/22/2019, 2:39 PM
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
s

svyatoslav.scherbina

02/22/2019, 3:06 PM
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
.
r

ribesg

02/22/2019, 3:14 PM
You can modify
NSError.userInfo["BugsnagError"]
? I thought
userInfo
was a
val
s

svyatoslav.scherbina

02/22/2019, 3:23 PM
You can modify contents of
NSError.userInfo["BugsnagError"]
, i.e. the object from
userInfo
.
r

ribesg

02/22/2019, 4:08 PM
Oh, you mean that I could modify the
BugsnagError
instance, like calling methods on it etc, but not replace it
s

svyatoslav.scherbina

02/22/2019, 5:25 PM
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.