<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Brian,<br><br>Thank you for your response!<br><br>> > I actually like Checked Exceptions. I think that, when<br>> > used correctly, they enable an easy to read style of<br>> > programming that separates the mess from the happy<br>> > path.<br>> <br>> This is an important point; for all the folks out there<br>> who love to thump the table with "Checked exceptions were<br>> a failed experiment", there are plenty of people who see<br>> value in them quietly getting work done.<br><br>In their defense, it took me a long time to "see the light" too.<br><br>Long story short, I had the great pleasure to work on a codebase at work that actually treats its Exceptions like first class citizens. Using my toy example from above, we might have had the directory creation Exception have a DirectoryNameClashException, which has subtypes clarifying the different types of name clash (clash with another directory, vs clash with a file on the rare OS that cares about that). So, you can use the Exception type to decide what to fail on and what to recover on.<br><br>> > I think Checked Exceptions are at their best when only<br>> > one method of a try block can throw a specific<br>> > exception. Meaning, there is no overlap between the<br>> > Checked Exceptions of methodA and methodB. This is<br>> > great because, then, you can wrap all "Throwable"<br>> > methods in a single try block, and then each catch has<br>> > a 1-to-1 mapping with the code that can throw it.<br>> <br>> I know what you mean, but I think there are several<br>> moving parts here. There is the checked-vs-unchecked<br>> dimension (which is a declaration-site property), which<br>> ideally is about whether the exception has a reasonably<br>> forseeable recovery. (FileNotFoundException is<br>> recoverable -- you can prompt the user for another file<br>> name, whereas getting an IOException on close() is not<br>> recoverable -- what are you going to do, close it again?)<br>> ...<br>> The point you raise is really more about the `try`<br>> statement than checked exceptions themselves<br><br>Thanks for helping translate my thoughts. Yes, try is really the target here. I was too focused on my specific use case to notice that at the time.<br><br>> So checked exceptions are best when they are signalling<br>> something that a user _wants_ to catch so they can try<br>> something else, and unchecked exceptions are better when<br>> there is no forseeable recovery other than log it, cancel<br>> the current unit of work, and then either exit or go back<br>> to the main event loop. <br><br>I appreciate you pointing this out. This is a way better mental model than I had.<br><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><br>I feel like the idea was mentioned before, but I never considered it like this. So, we could have the same, basic exception that we always had, but could now enhance the Exception to include metadata that we can now unbox with pattern-matching to get a more specific cause?<br><br>If so, that's a way better idea than mine. All existing Exception infrastructure stays as is, but underneath the surface, we can enhance the error throwing logic to include better detail. The example I gave above for FileAlreadyExistsException could include the offending path. Then, rather than having an Exception for clashing with a file and another for clashing with a directory, I can just have a clash exception that has a field to represent what I am clashing with, extract it via Pattern Matching, and maybe there is even a nested pattern on that object that tells me whether it is a file or directory.<br><br>It would mean we are leaning harder on the contracts of methods, but that actually sounds like a good thing. For example, in the past we would just say "if this failure happens, it will throw ExceptionA". Now, we might want to specify what metadata will be included in ExceptionA, so that users know what to extract, in case it isn't obvious.<br><br>In that case, I'll put my current idea to rest, since I see that Pattern Matching pretty much eclipses it in almost every single way. Hope to see this vein of pattern matching see the light of day soon!<br><br>Thank you for your time and help!<br>David Alayachew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 3, 2023 at 7:52 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>