https://kotlinlang.org logo
Join Slack
Powered by
I don’t know if this is Android specific or genera...
# android
t
I don’t know if this is Android specific or generally applicable. I just lost a day (at least) worth of work due to this little surprise: 
val family = 42
val friends = 0
println("Family:Friend ratio = ${family / friends}")
What my investigations some to indicate is that for many error exceptions (though not all), an exception inside of a ${} will cause the remainder of the calling context to be terminated and it just silently move on. Is this a known phenomenona? A temporary bug that is meant to be fixed? I’m using an up-to-date version of AndroidStudio.
😮 1
a
By looking at this I would say that the result should be "Family: Family....blabla.. NumberFormatterExceptuon{}". And it is not Android or AS it is Kotlin string templates. It will execute whatever is in {} and then append it to the string. So you can get Unit and the end of your string or the exception object just printed In the string
So I am not sure where the "shock" lies
If you execute it in the "evaluate" section in the debugger whatever it is evaluated to will be appended to the template as a string
m
exceptions aren't returned though. the shock is due to the fact that it doesn't crash
i wonder why it doesn't crash in android though. i just tried doing it in a kotlin gradle project and it correctly throws 
ArithmeticException
. maybe you're doing it in a background thread?
z
Are you setting a 
Thread.setDefaultUncaughtExceptionHandler()
somewhere that’s swallowing it?
m
i just tried it in android. it does crash the ui thread with 
java.lang.ArithmeticException: divide by zero
t
This is in a BLE callback, which I think is on a different thread. the os must be setting a different handler for these threads? Sorry for the false alarm.
Someday, I will find the person/people that did Bluetooth for Android. Let’s hope I can restrain myself when I do.
a
Lol I had a task for beacon detection and BLE use and based on my experience these people must be in witness protection 😅
a
they're quite nice people 🙂 being an expert in a particular kind of hardware does not always translate to app-level API usability.
we've had some chatter on and off about doing an 
androidx.bluetooth
library to help with a lot of these kinds of lifecycle and threading difficulties
these sorts of things are why most android APIs in the last several years are so strict about taking 
Executor, Callback
pairs
a
Yeah, we are joking. There is 2 sides of the issue: api usability and availability and hardware inconsistency across devices.
a
Yep. Which is another place where an androidx library might be able to help. The recent camerax library has been moving into trying to address hardware inconsistency as well as platform versioning
we're watching how that goes closely
a
Yeah exactly the same issue as the camera. We hope it is gonna move fast
a
the nice thing here is that it's rather easy for us to start new androidx libraries like this as kotlin-first and leverage things like coroutines to solve these sorts of api issues
a
Where is the petition to sign? 😆
😄 1
t
Having sampled a lot of the BLE libraries out there, the tricky part is that there’s a number of ways to use BLE. And every library author seems to think their particular approach to BLE interaction is just what everyone else wants. I know the following is probably heresy, but I’ve done 4 apps with somewhat different BLE approaches in iOS, and in each case the iOS library worked nicely. If someone made something that basically aped the iOS BluetoothCore interface and covered all of the bizarre Android gotchas, that would have my vote.
a
And it still wouldn't work on that Nokia 😅
t
@Zach Klippenstein (he/him) [MOD] I checked the default handlers, it’s the same between the callbacks and the main thread. So they must be explicitely trapping errors for each BluetoothGattCallback invocation.
Open in Slack
PreviousNext
Powered by