<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 30, 2018 at 10:48 AM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">Backing way up, Alex had suggested that the right exception is (a
    subtype of) IncompatibleClassChangeEXCEPTI<wbr>ON, rather than Error.  I
    was concerned that ICC* would seem too low-level to users, though. 
    But you're saying ICCE and subtypes are helpful to suers, because
    they guide users to "blame your classpath".  SO in that case, is the
    ICC part a good enough trigger?</div></blockquote><div><br></div><div>(Just to be clear, Remi and I have been advocating for a subtype of ICC<b>Error</b> all along, in case anyone missed that.)</div><div><br></div><div>All right, I've been focusing too much on the hierarchy, but the leaf-level name is more important than that (and the message text further still, and since I assume we'll do a fine job of that, I can probably relax a little). To answer your question, sure, the "ICC" is a pretty decent signal. Have we discussed Cyrill's point on -observers that we should create more specific exception types, such as UnrecognizedEnumConstantE{rror,xception}?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">For an enum in the same class/package/module as the switch, the
    chance of getting the error at runtime is either zero (same class)
    or effectively zero (same package or module), because all sane
    developers build packages and modules in an atomic operation.  <br>
    <br>
    For an enum in a different module as the switch, the chance of
    getting the error at runtime is nonzero, because we're linking
    against a JAR at runtime.  <br>
    <br>
    So an alternative here is to tweak the language so that the
    "conclude exhaustiveness if all enum constants are present" behavior
    should be reserved for the cases where the switch and the enum are
    in the same module?  <br>
    <br>
    (Just a thought.)<br>
  </div>

</blockquote></div><div class="gmail_extra"><br></div>Okay, that is a sane approach, but I think it leaves too much of the value on the floor. I often benefit from having my exhaustiveness validated and being able to find out at compile time if things change in the future.<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></div>