<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>À: </b>"Kevin Bourrillion" <kevinb@google.com><br><b>Cc: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Envoyé: </b>Vendredi 30 Mars 2018 19:48:03<br><b>Objet: </b>Re: Expression switch exception naming<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><blockquote cite="mid:CAGKkBkuKBR0_h0fBTe4dQyZmCCbNScuJfscU7Z0WOsjYJNFmRQ@mail.gmail.com"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Although the depth of this debate may
            seem to have exceeded its value in resolving the question at
            hand, I think it's usually worthwhile to try hammer out
            these kinds of differences, until we all have a greater
            common understanding (or clearly arrive at an impasse...).</div></div></div></blockquote><br>
    Nah, I'm not grumpy yet :)<br><br><blockquote cite="mid:CAGKkBkuKBR0_h0fBTe4dQyZmCCbNScuJfscU7Z0WOsjYJNFmRQ@mail.gmail.com"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Now, either this came to my attention
            through a compile-time or runtime error. If the former, it
            is clear what is going on, and is part of my normal workflow
            for how I get my code to work. If the latter, I'm suggesting
            that the best thing we can do is to prompt the developer to
            wonder "wait, why didn't I get a compile error?" so that it
            reduces to the former.</div></div></div></blockquote><br>
    Backing way up, Alex had suggested that the right exception is (a
    subtype of) IncompatibleClassChangeEXCEPTION, 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?  <br><br><blockquote cite="mid:CAGKkBkuKBR0_h0fBTe4dQyZmCCbNScuJfscU7Z0WOsjYJNFmRQ@mail.gmail.com"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>(The latter is a new
                idea, but I think is what you're getting at -- perhaps
                the rule should be that _within a module_, which is
                expected to be co-compiled, its OK to leave off the
                default, but for "foreign" enums/sealed types, we're not
                going to put any faith in the claim of sealed-ness, and
                make you handle the default explicitly?  <br></div></blockquote><div><br></div><div>I'm not sure I understand this, and therefore I suspect
              it's not what I'm getting at. :-)</div></div></div></div></blockquote><br>
    Expanding:<br><br>
    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.)</blockquote><div><br></div><div>Not having the same behavior due to a refactoring that introduces an intermediary module seems a big no no for me.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>