> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Kevin Bourrillion" <kev...@google.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 30 Mars 2018 19:48:03 > Objet: Re: Expression switch exception naming
>> 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...). > Nah, I'm not grumpy yet :) >> 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. > 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? >>> (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? >> I'm not sure I understand this, and therefore I suspect it's not what I'm >> getting at. :-) > Expanding: > 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. > 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. > 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? > (Just a thought.) Not having the same behavior due to a refactoring that introduces an intermediary module seems a big no no for me. Rémi
