Hi there! I am trying to add the CrashKiOS - Crash reporting for Kotlin/iOS for Bugsnag. The crashes...

# touchlab-tools

[Zsolt Bencze]

Hi there! I am trying to add the CrashKiOS - Crash reporting for Kotlin/iOS for Bugsnag. The crashes seem to be reported good from the iOS or Android code, but it seems to run into issues when it happens in the common code. E.g. if I force a crash with
fun deliberatelyCrash() {
throw Exception("This is a deliberate crash.")
}
or
val numbers = arrayOf(1)
print(numbers[20]

I get Function doesn't have or inherit @Throws annotation and thus exception isn't propagated from Kotlin to Objective-C/Swift as NSError.

Any insight on why this happens and what can be done?

[kpgalligan]

That's not a CrashKiOS thing. Your function doesn't have the @Throws annotation, so Kotlin will just crash rather than trying to send that as an NSError. And, honestly, that's fine. Kotlin has unchecked exceptions everything. Swift is 100% the opposite. You have to be very explicit with exceptions. This is more of a code design issue. If you are expecting an exception there, you should probably catch it and return some type of result optional with either the expected return or an error. Alternatively, you can add @Throws to that method, and then you'll need to try/catch from Swift, and deal with it that way.

[kpgalligan]

CrashKiOS comes in when you don't do any of that and the app actually crashes. Then you should get symbolicated crash logs in Bugsnag.

[kpgalligan]

In your case, since it looks like you're testing the crash support, your code is fine. It's supposed to crash.

[kpgalligan]

I don't remember off the top of my head where that message comes from, although I'm rather familiar with it. It's just saying that if you didn't want to crash, add a @Throws, basically.

[Zsolt Bencze]

Thanks Kevin. I added the @Throws to the method annotation 🤔 but did not consider catching it from the iOS side. You are likely right though, my background is mostly iOS, so my Android/KMM skills probably are lacking.

[kpgalligan]

OK, so you're trying to test that CrashKiOS is reporting crashes to Bugsnag, yes?

[Zsolt Bencze]

right

[Zsolt Bencze]

I wanted to see how the report shows up

[kpgalligan]

Then you don't want the @Throws. It should just "crash".

[Zsolt Bencze]

just to make sure I see what I want to see to be able to track down the bug later on

[kpgalligan]

Right

[kpgalligan]

I assume some button is triggering that from Swift?

[Zsolt Bencze]

It does crash, but it doesn't show up on Bugsnag 🤔

[Zsolt Bencze]

Yes, from swift

[Zsolt Bencze]

SwiftUI .. but right

[kpgalligan]

You're running from Xcode I assume?

[Zsolt Bencze]

correct

[Zsolt Bencze]

x.png

[Zsolt Bencze]

I get this alert, likely that's why it doesn't show up on Bugsnag.

[kpgalligan]

OK, tough question to explain, and if you have an iOS background I assume you've hit this before. Xcode steps in if you're "connected" to the session. So, if you run the app, you need stop it, then open it manually, then crash. If that's not the issue, then we'll have to think through other issues.

[kpgalligan]

Where/how are you running the app?

[Zsolt Bencze]

Yes, I figured I need to disconnect it from the debugger, so I did.. but it still happens, I still get that alert which puzzles me also

[kpgalligan]

That is odd. What's the startup code like? Bugsnag config, etc?

[Zsolt Bencze]

It's like the crash is not handled by anything, and then the OS catches it

[Zsolt Bencze]

From the iOS app:

import Bugsnag

let configuration = BugsnagConfiguration.loadConfig()
            let platformNativeComponent = PlatformNativeComponent(bugsnagConfiguration: configuration)
            InitializerKt.doInitApp(platformNativeComponent: platformNativeComponent, appDeclaration: { _ in }

and then the commonMain would initialize (this is the doInitApp) and call:
initializeAndStartErrorReporting(platformNativeComponent)
which is an expect/actual,

and in the iOSMain

actual fun initializeAndStartErrorReporting(platformNativeComponent: PlatformNativeComponent) {
  startBugsnag(platformNativeComponent.bugsnagConfiguration)
}

where the import for startBugsnag is import co.touchlab.kermit.bugsnag.startBugsnag

[kpgalligan]

Kermit version?

[Zsolt Bencze]

1.2.2

"co.touchlab:kermit-gradle-plugin:1.2.2"
"co.touchlab:kermit:1.2.2"

[Zsolt Bencze]

id("co.touchlab.crashkios.bugsnaglink") version "0.8.2"

[kpgalligan]

That's pretty old. We're currently on 2.0.2 (https://github.com/touchlab/Kermit/releases/tag/2.0.2). In theory, it should still configure bugsnag, but newer versions of bugsnag changed some of the private calls we needed to make in their Objc, so you'll likely need to use newer versions anyway, assuming you're using a recent bugsnag version on iOS https://github.com/touchlab/CrashKiOS/pull/57

[Zsolt Bencze]

Okay. Good point. Let me update kermit, and give it a go! Thanks a lot Kevin, appreciated.

[Zsolt Bencze]

Bugsnag (6.26.2)

[kpgalligan]

You're welcome! Now, as an fyi, we're having some difficulty with Kotlin 1.9 (ish) and linking for tests. Previously that would work if you turned off compiler caching, which wasn't a great solution, but we've had trouble with that lately as well. The issue is we want Kotlin to have cinterop access to bugsnag (or crashlytics, same problem), but I don't want the Kotlin build to inject that library into the build, assuming the iOS app will manage and define that. If you just build the framework, the linker can hold off on trying to resolve that until Xcode builds the full app, but tests in the Kotlin compiler attempt to link that and can't find it. For that and other reasons, I'm thinking through and approach where we try to step in and do our calls to Bugsnag from Kotlin dynmaically rather than directly linking, but It's been a busy few weeks over here, and haven't really had time to think that through. Anyway, just fyi. id("co.touchlab.crashkios.bugsnaglink") version "0.8.2" only handles that for the framework build, not the test build.

[Zsolt Bencze]

Thanks for the heads-up. I am on 1.8.10 as of now.

[Zsolt Bencze]

Seems to work now after the upgrade. Thanks.