Some thoughts and an idea about Checked Exceptions

[Brian Goetz]

A good rule of thumb here is: if you're not the JVM runtime, don't think 
about extending Error. (But there are plenty of counterexamples to muddy 
these waters, such as javax.xml.parsers.FactoryConfigurationError.)

The rubric you outline is good in theory, except for the fact that it is 
hard to know a development time whether a condition is really 
unrecoverable or not (unless you're the JVM runtime.)

On 12/4/2023 10:57 AM, Nathan Reynolds wrote:
> Brian,
>
> 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?
>
> On Sun, Dec 3, 2023 at 7:01 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
>>
>>     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.
>
>     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.
>
>>     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.
>
>     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.
>
>     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.
>
>     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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231204/46d58103/attachment-0001.htm>