So, errors and iOS. Looking at <https://github.com...
# kotlin-native
k
So, errors and iOS. Looking at https://github.com/JetBrains/kotlin-native/blob/master/OBJC_INTEROP.md, it mentions if we want to have an explicit throw check, add @Throws, but I have some more questions. If calling directly into kotlin code from swift (and presumably objc), on a method without @Throws, if the code throws an exception the app will crash. This is what I’d expect to happen. However… (to thread)
l
However… (to thread)
Is the end missing?
k
Still working. Also looking at kotlin-native code
We’re using a worker to implement concurrency on the iOS side. By default, that prints the exception to the log, but ideally we’d want to implement something similar
(remembered I was in the middle of looking, then got distracted)
Just kind of thinking out loud about strategies to get that to crash “properly” in a deployed app (and wind up in crashlytics, etc). The “simple” answer is moving the threading to iOS code and being super careful with the state/freezing (etc), but wondering if some of the more iOS experienced know how to tell the system “crash here” and preserve that stack trace. Does that make sense? Regardless, if direct calls crash but worker calls print but keep going, that situation should be different.
What are others planning/doing for their apps?
Well, probably not “recommended”, but this works. Add a reference to the C++ method used by interop to write to iOS crash log, wrap and call that from worker execute
b
if you use coroutines, I think I saw somewhere that there's a global exception handler you can hook into