<!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>