<div dir="ltr"><div>Brian, </div><div><br></div><div>Thank you for explaining when to use checked and unchecked exceptions.  I've wondered a while about this.  When do I use RuntimeException versus Error?  Do I use RuntimeException for when the current task needs to exit?  Do I use Error when the current program needs to exit?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 3, 2023 at 7:01 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:monospace"><br>
          I actually like Checked Exceptions. I think that, when used
          correctly, they enable an easy to read style of programming
          that separates the mess from the happy path.<br>
        </div>
      </div>
    </blockquote>
    <br>
    This is an important point; for all the folks out there who love to
    thump the table with "Checked exceptions were a failed experiment",
    there are plenty of people who see value in them quietly getting
    work don.  <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:monospace">I think
          Checked Exceptions are at their best when only one method of a
          try block can throw a specific exception. Meaning, there is no
          overlap between the Checked Exceptions of methodA and methodB.
          This is great because, then, you can wrap all "Throwable"
          methods in a single try block, and then each catch has a
          1-to-1 mapping with the code that can throw it.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I know what you mean, but I think there are several moving parts
    here.  There is the checked-vs-unchecked dimension (which is a
    declaration-site property), which ideally is about whether the
    exception has a reasonably forseeable recovery. 
    (FileNotFoundException is recoverable -- you can prompt the user for
    another file name, whereas getting an IOException on close() is not
    recoverable -- what are you going to do, close it again?)  So
    checked exceptions are best when they are signalling something that
    a user _wants_ to catch so they can try something else, and
    unchecked exceptions are better when there is no forseeable recovery
    other than log it, cancel the current unit of work, and then either
    exit or go back to the main event loop.  <br>
    <br>
    The point you raise is really more about the `try` statement than
    checked exceptions themselves; the main body of a `try` is a block
    statement.  The block might do IO in a dozen places, but most of the
    time, we want to treat them all as "some IO operation in this block
    failed"; it is rare that we want to separate failure on a write from
    failure on a close.  Of course, there are "exceptions" to every
    rule.  Catch was also later extended to let you handle multiple
    exceptions with the same handler (catch IOE|SQLE), which further
    fits into the "aggregation" aspect of try-catch.  <br>
    <br>
    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, whcih currently are restricted to
    the type of the exception, there is much room to refine the
    specificity of such patterns.<br>
    <br>
    <br>
  </div>

</blockquote></div>