<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAA9v-_P2aOODRfKzz0rmgygb7n7dgk5CQRQaWVzZ0OREN9ukKw@mail.gmail.com">
<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" cite="mid:CAA9v-_P2aOODRfKzz0rmgygb7n7dgk5CQRQaWVzZ0OREN9ukKw@mail.gmail.com">
<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>
</body>
</html>