<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">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.) <br>
<br>
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.) <br>
</font><br>
<div class="moz-cite-prefix">On 12/4/2023 10:57 AM, Nathan Reynolds
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CALMUwcpCt31CtGgCK0=Hxdsj6X9DRj0M8vUjxXGvgtvjB-yAtA@mail.gmail.com">
<div dir="ltr">
<div>Brian, </div>
<div><br>
</div>
<div>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?<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Dec 3, 2023 at 7:01 PM
Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">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">
<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>
</blockquote>
<br>
</body>
</html>