> From: "John Hendrikx" <[email protected]> > To: "Remi Forax" <[email protected]>, "Nathan Reynolds" > <[email protected]> > Cc: "amber-dev" <[email protected]>, "amber-spec-experts" > <[email protected]>, "Ron Pressler" > <[email protected]> > Sent: Saturday, November 12, 2022 5:16:10 PM > Subject: Re: Retiring Checked Exceptions Was: Throwing Functions
> I very much disagree with this position, so I will make a case for checked > exceptions: > 1) Without checked exceptions, using exceptions for alternative outcomes as > part > of the contract of an API would no longer be possible. This is because adding > a > new exception to the API would no longer be a breaking change. Documentation > is > not going to save you here. Effectively, exceptions would have only two uses > left (like in other languages): fatal JVM breaking errors and to signal > mistakes that could have been prevented by the programmer. Using them to > signal > unpreventable errors would be highly suspect and likely quickly be considered > a > bad practice. > In other languages (but also in some Java API's that use runtime exception to > signal unpreventable errors) the compiler cannot help you with these > alternative outcomes as it isn't even required to specify them as part of your > API. It helps you with the return value, but not for any other outcomes. These > other outcomes will now have to guessed, gleaned from the documentation (if it > is up to date), or by doing manual code mining (of the called function and all > the functions it calls). Worse, these outcomes can change in later releases > without any warning as they're non-breaking changes. I'm proposing to demote checked exceptions to make them second class citizen because this practically what they are. The problem is that the status quo is pushing people to use runtime exceptions instead of exceptions because checked exception do not compose well, exactly what we both do not want. Are you aware that Files.lines() or Files.list() are throwing UncheckedIOException ? Libraries are already hiding checked exceptions inside unchecked ones. The end game if we do nothing is that nobody will use Exception anymore because they will be hidden inside an unchecked one. I think it's far better to consider them as documentation with a warning, exacly like a a cast to a type variable or a parametrized type emit a warning that that current practice which is to hide checked exceptions inside unchecked ones. Rémi
