Retiring Checked Exceptions Was: Throwing Functions

[Stephen Colebourne]

I outlined simple, practical approach to this when lambdas were first added
to Java [1]. Much of the blog post above is no longer especially
interesting, but the basic "lone throws" concept still is. The key part is
repeated in these three bullet points:

* Any method may have a throws keyword without specifying the types that
are thrown ("lone-throws"). This indicates that any exception, checked or
unchecked may be thrown. Once thrown in this manner, any checked exception
flows up the stack in an unchecked manner.
* Any catch clause may have a throws keyword after the catch. This
indicates that any exception may be caught, even if the exception isn't
known to be thrown by the try block.
* All closures are implicitly declared with lone throws. Thus, all closures
can throw checked and unchecked exceptions without declaring the checked
ones.


I suspect it is too late for the last bullet point to be adopted, but the
first two would IMO still be hugely beneficial to Java. The point here is
not to reject the idea of checked exceptions, but to provide a convenient
way to convert/handle them when they are not what you want.

Various alternative mechanisms are in use today:
* additional functional interfaces such as ThrowableFunction
* utilities like Unchecked.wrap(ThrowableSupplier) which convert checked to
unchecked
* hacks like "sneaky throw"
My argument is that there is a very clear use case in the global corpus of
Java code for a mechanism to convert/handle checked exceptions more like
unchecked. And that this would be a good language feature, given that it
can be done without threatening those who appreciate checked exceptions.

Stephen


[1]
https://blog.joda.org/2010/06/exception-transparency-and-lone-throws_9915.html?m=1

On Mon, 14 Nov 2022, 23:09 Archie Cobbs, <archie.cobbs at gmail.com> wrote:

> On Mon, Nov 14, 2022 at 4:52 PM <forax at univ-mlv.fr> wrote:
>
>> 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.
>>
>
> I totally agree that the lack of composibility (composibleness?) is a
> problem. But I don't agree that ALL of the blame for that problem rests on
> checked exceptions. After all, checked exceptions have been around a lot
> longer than lambdas.
>
>
>> What if checked exceptions work like unchecked casts ?
>>
>
> This sounds like a much more promising direction to go in.
>
> All we want is a simple way to tell the compiler "I know this lambda can
> throw a checked exception, just pass it through instead of making this
> impossible to compile".
>
> E.g. something like this??
>
> public <T> void execute(@PassThroughCheckedExceptions Supplier<T> getter)
> {
>     return getter.get();
> }
>
> public InputStream openFile(File file) throws IOException {
>     this.execute(FileInputStream::new);
> }
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221115/c64e35ce/attachment.htm>