Retiring Checked Exceptions Was: Throwing Functions

[forax at univ-mlv.fr]

> From: "John Hendrikx" <hjohn at xs4all.nl>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Nathan Reynolds"
> <numeralnathan at gmail.com>
> Cc: "amber-dev" <amber-dev at openjdk.org>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>, "Ron Pressler" <ron.pressler at oracle.com>
> 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221114/dd066069/attachment.htm>