2 ms·

> This however runs into issues. One really annoying one: Checked exceptions are part of your API. If you forget an error condition and want to introduce a new

> This however runs into issues. One really annoying one: Checked exceptions are part of your API. If you forget an error condition and want to introduce a new exception for that, well guess what, that's a breaking API change. There is no easy way to evolve an API with checked exceptions, because changing them requires new major versions, because it prevents code from compiling. This sounds like a good thing. Throwing a new exception is a breaking change whether it's enforced by the compiler or not. Otherwise, callers of you API go from being exception safe to not being exception safe. It's strange to me that you would want to squirm around that just to avoid bumping the version number.

tetha 3y ago
That's not true in java. You can gradually increase the granularity of unchecked exceptions using subtypes. For example I might initally have AnythingFailedDuringTheQueryException with a Subtype of QueryPreparationException. If I introduce new subclasses of QueryPreparationException to increase the precision of the error reporting, all existing catches for QueryPreparationException will still function as they did before. A "NotEnoughParametersException" subclass of a QueryPreparationError is still caught as a QueryPreparationError. Only if you introduce catches for the new more granular unchecked exception, your codes behavior changes to use the new behavior. That's a very clean way to improve error reporting in a backwards compatible way.