Checked exceptions aren't as nice as reporting errors directly via return types but it's a whole lot better than unchecked exceptions
I can't understand why people hate checked exceptions so much and I find Kotlin removing them to be a huge downgrade when using Java libraries.
Conversation
Replying to
Kotlin's unchecked exceptions are my single biggest pain point when developing for Android.
Coming from Rust, I'd much rather be forced to catch exceptions I don't care about than dig to find (or guess) which ones can be thrown from a given function call.
2
Replying to
We've had a lot of issues with it for the Camera app and I've now reluctant to migrate anything to Kotlin without having a lint to force handling checked exceptions from Java APIs. The way it handles null for FFI is also really fragile especially with Java APIs being encouraged.
1
Essentially, we're going to have to go through every method call we're making to check to the Java API signatures for checked exceptions. There doesn't seem to be tooling to help with it. It's genuinely really bad and while Kotlin is much prettier this is a major regression.
1
Replying to
That's especially unfortunate since many Jetpack libraries are now being developed Kotlin-first or Kotlin-exclusive (e.g. Jetpack Compose). I understand why Kotlin is better than Java in many regards and generally prefer it, but error handling w/Java interop feels half-baked
1
2
Replying to
It's a nicer language than Java in most ways but it's really held back by the close ties to Java and especially the library ecosystem without a culture of wrapping the Java libraries into whatever idiomatic Kotlin is. Hard to know since using Java types/libraries is idiomatic.

