Some thoughts and an idea about Checked Exceptions

[Brian Goetz]

>
> 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/20231203/92a9c8fb/attachment.htm>