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
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
Replying to
It's still a breaking change even if the API signature doesn't change. The way to prevent it from being a breaking change is to throw it as one of the already included checked exception types. If the function didn't throw and now does throw, that is itself the breaking change.
2
1
Being against checked exceptions for that reason is simply being against static typing. Java has such a terrible type system that I can understand why it turns people against typing but for the most part I don't actually see much issue with how it handles checked exceptions.
1
1
My stance would be that unchecked exceptions should only ever be used for logic errors or serious issues with the execution environment being broken. That means you either report errors with return values or checked exceptions, and Java's type system is terrible at the former.
1
2
Kotlin doesn't really do enough to resolve it. It's missing forcing handling return values so it's a bad way to report errors for a side effect failing. Kotlin doesn't have proper sum types and I have a hard time seeing how they expect people to report errors in a reasonable way.