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.

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

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

Are you setting a

Thread.setDefaultUncaughtExceptionHandler()

somewhere that’s swallowing it?

i just tried it in android. it does crash the ui thread with

java.lang.ArithmeticException: divide by zero

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.

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

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

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

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

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

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

Where is the petition to sign? 😆

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.

And it still wouldn't work on that Nokia 😅

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