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.
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
Show replies
Replying to
Some library maintainers do odd things though re not introducing breaking changes and it ends up being fairly limiting at times ... issues.apache.org/jira/browse/FI 🤷♀️
1
Replying to
If they're willing to silently break code by adding or changing unchecked exceptions used for error reporting, they're just pretending to have backwards compatibility when they don't actually provide it. It's just dynamic typing instead of static typing. It's still incompatible.
2