<div dir="auto"><div dir="auto">Hello Brian,</div><div dir="auto"><br></div>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!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 4, 2023, 11:42 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
  <div>
    <br>
    <blockquote type="cite">
      <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>
  </div>

</blockquote></div>