Some thoughts and an idea about Checked Exceptions

[Brian Goetz]

>
> > The proposal you make, which basically allows users to
> > associate invocation context with a region of code that
> > is attached to any exceptions thrown from that region, is
> > interesting but likely too specialized to be broadly
> > useful. Attaching metadata to exceptions is a rich and
> > useful vein of ideas (including attaching context
> > information useful in debugging or diagnosing test
> > failure), but this one seems at the narrow end of that
> > vein. But, if you look at catch clauses as pattern
> > matches, which currently are restricted to the type of
> > the exception, there is much room to refine the
> > specificity of such patterns.
>
> WOW - the pattern matching well is bottom less.

Here are some relatively-unformed thoughts on how `catch` clauses could 
align with patterns.

     catch (IOException e) { ... }

This can be interpreted cleanly as a type pattern already, with the 
exception thrown as the match candidate.

Just as we have alternate constructors for most exceptions for wrapping:

     FooException()
     FooException(String)
     FooException(Throwable)
     FooException(String, Throwable)

we can similarly have matching deconstructors in the exception classes, 
meaning we could use ordinary nested patterns to detect wrapped exceptions:

     catch (RuntimeException(IOException e)) { ... }

If needed, guards can be introduced into catch clauses as they were in 
switch cases, with basically the exact same set of rules for 
dominance/exhaustiveness/flow analysis:

     catch (SqlException e) when e.getErrorCode() == 666 { ... }

Catch clauses currently have an ad-hoc syntax for union types which is 
not currently supported by type patterns, so there would have to be some 
reconciliation there.

(Usual disclaimer: this stuff is all off in the future, not currently on 
the plate, deep-diving on the design now is now probably counterproductive.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231204/20ed49fe/attachment.htm>