I don’t know if this is Android specific or generally applicable. I just lost a day (at least) worth...

# android

[Travis Griggs]

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.

[Anastasia Finogenova]

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

[Anastasia Finogenova]

So I am not sure where the "shock" lies

[Anastasia Finogenova]

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

[mon]

exceptions aren't returned though. the shock is due to the fact that it doesn't crash

[mon]

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?

[Zach Klippenstein (he/him) [MOD]]

Are you setting a Thread.setDefaultUncaughtExceptionHandler() somewhere that’s swallowing it?

[mon]

i just tried it in android. it does crash the ui thread with java.lang.ArithmeticException: divide by zero

[Travis Griggs]

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.

[Travis Griggs]

Someday, I will find the person/people that did Bluetooth for Android. Let’s hope I can restrain myself when I do.

[Anastasia Finogenova]

Lol I had a task for beacon detection and BLE use and based on my experience these people must be in witness protection 😅

[Adam Powell]

they're quite nice people 🙂 being an expert in a particular kind of hardware does not always translate to app-level API usability.

[Adam Powell]

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

[Adam Powell]

these sorts of things are why most android APIs in the last several years are so strict about taking Executor, Callback pairs

[Anastasia Finogenova]

Yeah, we are joking. There is 2 sides of the issue: api usability and availability and hardware inconsistency across devices.

[Adam Powell]

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

[Adam Powell]

we're watching how that goes closely

[Anastasia Finogenova]

Yeah exactly the same issue as the camera. We hope it is gonna move fast

[Adam Powell]

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

[Anastasia Finogenova]

Where is the petition to sign? 😆

[Travis Griggs]

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.

[Anastasia Finogenova]

And it still wouldn't work on that Nokia 😅

[Travis Griggs]

@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.