https://kotlinlang.org logo
#android
Title
# android
t

Travis Griggs

03/27/2020, 10:23 PM
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

Anastasia Finogenova

03/28/2020, 1:57 AM
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

mon

03/28/2020, 3:47 AM
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

Zach Klippenstein (he/him) [MOD]

03/28/2020, 4:08 AM
Are you setting a
Thread.setDefaultUncaughtExceptionHandler()
somewhere that’s swallowing it?
m

mon

03/28/2020, 4:30 AM
i just tried it in android. it does crash the ui thread with
java.lang.ArithmeticException: divide by zero
t

Travis Griggs

03/28/2020, 4:57 AM
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

Anastasia Finogenova

03/28/2020, 1:40 PM
Lol I had a task for beacon detection and BLE use and based on my experience these people must be in witness protection 😅
a

Adam Powell

03/28/2020, 2:34 PM
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

Anastasia Finogenova

03/28/2020, 2:36 PM
Yeah, we are joking. There is 2 sides of the issue: api usability and availability and hardware inconsistency across devices.
a

Adam Powell

03/28/2020, 2:37 PM
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

Anastasia Finogenova

03/28/2020, 2:38 PM
Yeah exactly the same issue as the camera. We hope it is gonna move fast
a

Adam Powell

03/28/2020, 2:39 PM
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

Anastasia Finogenova

03/28/2020, 2:48 PM
Where is the petition to sign? 😆
😄 1
t

Travis Griggs

03/28/2020, 8:53 PM
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

Anastasia Finogenova

03/28/2020, 8:54 PM
And it still wouldn't work on that Nokia 😅
t

Travis Griggs

03/28/2020, 9:04 PM
@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.