Some thoughts and an idea about Checked Exceptions

[Nathan Reynolds]

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/15f2003f/attachment.htm>