I think we are the heart of the disagreement. I do not think that
"someone added an enum constant" is necessarily a classpath insanity
thing. Its just as likely to be a garden-variety "you made one
assumption over here and another over there" within the same codebase.
(And, we've told people
Summarizing what I heard: seeing Error is your trigger to "go fix your
classpath and recompile". And implicitly, you're saying: if it is an
exception (no matter how clearly worded about inconsistent assumptions
across classes), it is far less likely to trigger this reaction?
(And, we've
I do not see (B) as sacrifying the consistency because the premise is that an
expression switch should be consistent with ?:
But an expression switch can also be modeled as a classical switch that returns
it's value to a local variable.
int a = switch(foo) {
case 'a' -> 2;
case 'b' ->
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...).
On Fri, Mar 30, 2018 at 9:3
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 ye
On Fri, Mar 30, 2018 at 10:48 AM, Brian Goetz
wrote:
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
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.
> De: "Brian Goetz"
> À: "Kevin Bourrillion"
> Cc: "amber-spec-experts"
> 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 wo
You still have not explain why you want to recover from one of these exception
knowning that it's simpler to add a default if you want to take care of an
unknown enum constant.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Kevin Bourrillion"
> Cc: "amber-spec-experts"
> Envoyé: Ve
I'm not talking about recovering. This is purely taxonomy; this sort of
mismatch does not (IMO) rise to the level of Error.
On 3/30/2018 2:42 PM, Remi Forax wrote:
You still have not explain why you want to recover from one of these exception
knowning that it's simpler to add a default if you
Do we have another case where we actually throw a runtime exception due to a
separate compilation issue ?
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Kevin Bourrillion" , "amber-spec-experts"
>
> Envoyé: Vendredi 30 Mars 2018 20:44:23
> Objet: Re: Expression s
On 2018-03-30T14:39:30 -0400
Brian Goetz wrote:
>
> To be clear, I was describing:
> - We'd always do exhaustiveness checking for expression switches
> - A default / total pattern always implies exhaustive
> - We'd additionally consider an expression switch to be exhaustive if
> all known e
Yes, you misunderstood :)
You would always get an exhaustiveness check. What you'd not get is the
"grace" of having said:
case RED:
case YELLOW:
case GREEN:
without a default, and having that still be considered exhaustive
because these are all the alternatives known at compile tim
On 2018-03-30T15:10:32 -0400
Brian Goetz wrote:
> Yes, you misunderstood :)
>
> You would always get an exhaustiveness check. What you'd not get is the
> "grace" of having said:
>
> case RED:
> case YELLOW:
> case GREEN:
>
> without a default, and having that still be considered
It's not clear to me what the utility of nominally always having an
exhaustiveness check would be if I end up having to include a "default"
everywhere anyway. If someone adds an enum constant (and I'm compiling
my code against their new code), I want to get compilation errors in
every switch tha
On 2018-03-30T16:17:35 -0400
Brian Goetz wrote:
>
> OK, we have a terminology confusion over the term "exhaustiveness
> checking."
Got it, I'm up to speed!
> But, your point is taken; *not* having a default in a situation that
> requires exhaustiveness acts as a type-check on that exhaustivene
> On Mar 30, 2018, at 10:54 AM, Remi Forax wrote:
>
> I do not see (B) as sacrifying the consistency because the premise is that an
> expression switch should be consistent with ?:
>
> But an expression switch can also be modeled as a classical switch that
> returns it's value to a local varia
17 matches
Mail list logo
