Expression switch exception naming

Dear experts, We're busy putting the finishing touches to the spec for expression switches. Here's one issue that came up that we'd like your opinion on. Here is a part of the spec that deals with the dynamic semantics of expression switch - If no pattern matches and there is no `default`

Re: Expression switch exception naming

On 2018-03-28T14:15:33 +0100 Gavin Bierman wrote: > > A worry here might be that other future features might want to raise this > exception, and the name will be less applicable. Perhaps > "UnexpectedValueException"? Is this really a worry? I mean, it's not really as

Re: Expression switch exception naming

Using a runtime exception is like another less readable way to do exactly that. It's both less and more readable. Its less readable in that its implicit in the code, rather than explicit.  But its probably the case that the exception thrown implicitly will be more informative to the

Re: Expression switch exception naming

ICCE indicates that a _binary incompatible_ change was detected, which by definition the client cannot recover from.  Adding an enum constant is not a binary incompatibility (though removing one is).  (Interestingly, neither is changing an enum to a class, if you have static fields for all the

Re: Expression switch exception naming

Given that you can explicitly add a default target, it's an opt-in mechanism, if you add you own 'default' target, you explicitly say how you want to recover to an enum constant you do not known. Using a runtime exception is like another less readable way to do exactly that. Rémi - Mail

Re: Records -- current status

> On Mar 20, 2018, at 8:15 AM, Brian Goetz wrote: > >> >> So add all this up and we have three kind of finalness for fields: >> >> - by default mutable, but you can change it >> - by default final, and you can't change it >> - (and now) by default final, but you can

Re: Expression switch exception naming

NoCaseMatchError (or any other name) which is a subtype of IncompatibleClassChangeError. I buy the "subtype of ICCE" argument, but it seems to me these need to be exceptions, not errors.  (Thought experiment: if we already had both ICC{Exception,Error}, would we have jumped so fast to