<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAA9v-_PUJK35LmijKm9ps_vtwaxJX+VGQfh5V-JOiKEjy1GBow@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-family:monospace"><br>
> The proposal you make, which basically allows users to<br>
> associate invocation context with a region of code that<br>
> is attached to any exceptions thrown from that region, is<br>
> interesting but likely too specialized to be broadly<br>
> useful. Attaching metadata to exceptions is a rich and<br>
> useful vein of ideas (including attaching context<br>
> information useful in debugging or diagnosing test<br>
> failure), but this one seems at the narrow end of that<br>
> vein. But, if you look at catch clauses as pattern<br>
> matches, which currently are restricted to the type of<br>
> the exception, there is much room to refine the<br>
> specificity of such patterns.<br>
<br>
WOW - the pattern matching well is bottom less.<br>
</div>
</div>
</blockquote>
<br>
Here are some relatively-unformed thoughts on how `catch` clauses
could align with patterns. <br>
<br>
catch (IOException e) { ... }<br>
<br>
This can be interpreted cleanly as a type pattern already, with the
exception thrown as the match candidate. <br>
<br>
Just as we have alternate constructors for most exceptions for
wrapping:<br>
<br>
FooException()<br>
FooException(String)<br>
FooException(Throwable)<br>
FooException(String, Throwable)<br>
<br>
we can similarly have matching deconstructors in the exception
classes, meaning we could use ordinary nested patterns to detect
wrapped exceptions:<br>
<br>
catch (RuntimeException(IOException e)) { ... }<br>
<br>
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: <br>
<br>
catch (SqlException e) when e.getErrorCode() == 666 { ... }<br>
<br>
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. <br>
<br>
(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.)<br>
<br>
<br>
</body>
</html>