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 stance is essentially that you shouldn't be reporting errors with exceptions, which is all well good except it's heavily designed around Java interoperability. Even without Java 'FFI', it doesn't have a way to force you to handle a return value like #[must_use] in Rust.
7
Replying to
There can be issues around checked exceptions and maintaining/breaking backwards compatibility for libraries 🤷♀️
1
Replying to
Changing the exceptions that are thrown is always breaking backwards compatibility. If it's not well defined the API is poorly specified. It's better if it's reflected in the API and prompts people to handle the new error. It can easily be dealt with in an automated way.
1
1
Show replies
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
Show replies