<div dir="ltr">I think my overarching point is still this one:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>"Today, an experienced developer knows that there is a category of Errors that, when you see them in the absence of reflection, always implicate this kind of classpath issue. I can't see why this would not belong in that same category."</div></blockquote><div><br></div><div>The distinction, when a stack trace has just ruined my day, of whether I need to start thinking hard about what <i>real</i> mistake I might have made <i>in my code, </i>or whether I probably just have Class Path Insanity I should check out first, seems to be like a very high order distinction - more useful to illuminate than other various distinctions we can make.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 28, 2018 at 12:48 PM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<tt><br>
</tt><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>I have been figuring that if the client <i>has</i>Â a
reasonable way to handle unknown values then it will
probably go ahead and do that (with a `default`).</div>
</div>
</div>
</div>
</blockquote>
<br></span>
I think that's a fair assumption for your codebase, but not in
general. Developers will surely do this:<br>
<br>
   x = switch (trafficLight) {<br>
       case RED -> ...<br>
       case YELLOW -> ...<br>
       case GREEN -> ...<br>
   }<br>
<br>
and leave out a default because they can. So they get a default
default, one that throws. No problem. <br>
<br>
The only question here is: what to throw. My argument is that Error
is just too strong an indicator. (It's like using fatal as your
logging level for everything; it would be more useful to use warning
for things that aren't fatal).<tt><br>
<br>
From the Error doc:<br>
</tt><br>
<tt><span>An<span>Â </span></span><code style="font-family:"DejaVu Sans Mono",monospace;font-size:14px;padding-top:4px;margin-top:8px;line-height:1.4em;color:rgb(71,71,71);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Error</code><span><span>Â </span>is
a subclass of<span>Â </span></span><code style="font-family:"DejaVu Sans Mono",monospace;font-size:14px;padding-top:4px;margin-top:8px;line-height:1.4em;color:rgb(71,71,71);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Throwable</code><span><span>Â </span>that indicates serious
problems that a reasonable application should not try to catch.
Most such errors are abnormal conditions.<span> </span></span><br>
<br>
Serious problems mean that underlying VM mechanism have failed.Â
Encountering an unexpected input is not in this category. Sure,
it deserves an exception, but its not an ICCE. </tt><br><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Therefore I assumed that what we're talking about in
this conversation is the<i> other</i> kind, where there is
nothing safe they can do - for example if I wrote a method
that displays a time interval as "10 ns" or "20 s", I may
not find it acceptable for me to start displaying "30
<unknown unit>" once I get handed TimeUnit.DAYS. My
code is broken either way. If a constant is added, I need
to react to that, just like I do with a new interface
method. What does it really mean to say that this client
"brings a piece of the responsibility" if it doesn't
really have a choice?</div>
</div>
</div>
</div>
</blockquote>
<br></span>
It's not unlike this:<br>
<br>
   AnEnum e = f(...);<br>
   switch (e) {<br>
       ...<br>
   }<br>
<br>
and not being prepared for a null. You'll get an NPE. The local
code isn't expected to deal with it, but somewhere up the stack,
someone is prepared to deal with it, discard the offending incoming
work item, log what happened, and re-enter the work loop. <br><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>So, I'm not quite yet following why the binary/source
compatibility distinction, or the opt-in distinction,
really makes all the difference here.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Some incompatibilities are more of a fire drill than others. Binary
incompatibilities (e.g., removing a method) are harder to recover
from than unexpected inputs. Further, while there may be no good
_local_ recover for an unexpected input, there often is a reasonable
global recovery. Error means "fire drill". I claim this doesn't
rise to the level of Error; it's more like NumberFormatException or
NPE or ClassCastException. <br>
<br>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>
</div>