Some thoughts and an idea about Checked Exceptions

[David Alayachew]

Hello Brian,

Thanks for the rundown, I really appreciate it! I'll avoid digging further
like you said, but the future looks bright for java. Thanks again for the
peek into the potential future!

On Mon, Dec 4, 2023, 11:42 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> > 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/d6bc4942/attachment.htm>