[pattern-switch] Exhaustiveness

[Aaron Scott-Boddendijk]

> 1.  Box(null) is part of the remainder of `case Box(Bag(var x))`, and
> should be thrown on if the switch is total.  But ICCE is not an accurate
> description of what happened here; there has not been an incompatible
> class change, but instead simply a putatively total switch combined with
> an "acceptably leaky" set of cases.  The semantics here are "I got a
> value that the user didn't handle, but the user and the compiler made a
> deal that its OK to not handle that value, because its a silly value, so
> this exception serves as notice of that."  That's not ICCE.

Could j.l.UnsupportedOperationException serve here (if we dropped the
docs suggesting it's specific to the Collections framework)?

If the value leaks, and an exception is the expected outcome when that
happens, it's because we have opted not to support switching on that value.

The only information-lossy scenarios would arise if the expression to the
switch statement has a call that itself yields this exception but I would
think
it would be enough to provide text in the exception message that indicates
that the cause was a switch.

--
Aaron Scott-Boddendijk


On Tue, Sep 1, 2020 at 4:37 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> The answer is twofold; one is a correctness argument, and the other is a
> practical one.
>
> 1.  Box(null) is part of the remainder of `case Box(Bag(var x))`, and
> should be thrown on if the switch is total.  But ICCE is not an accurate
> description of what happened here; there has not been an incompatible
> class change, but instead simply a putatively total switch combined with
> an "acceptably leaky" set of cases.  The semantics here are "I got a
> value that the user didn't handle, but the user and the compiler made a
> deal that its OK to not handle that value, because its a silly value, so
> this exception serves as notice of that."  That's not ICCE.
>
> You could argue "well, then NPE."  Which is also not quite accurate,
> since no one tried to dereference the null reference.  But it might be
> close enough to get away with.  But then, what about something like
> `case TwoBox(Bag(var x), Shape s)` when confronted with a `new
> TwoBox(null, NovelSubtypeOfShape)`?  The latter smells like ICCE, the
> former like NPE.  Which should win?  We could specify this, but ....
> this brings me to my second answer.
>
> 2.  How much effort is it worth spending on coming up with a scheme to
> perfectly classify what exception should be thrown on remainder? And, do
> you have any idea how much JCK is then going to have to spend testing
> all the assertions about the difference of what should be thrown in
> weird nested cases?  And then, what happens when Eclipse implements it
> differently?
>
> Having seen how expensive it to adjudicate spec/JCK challenges ("you
> threw AME when I think the spec says you should have thrown ICCE"),
> we've learned not to create those situations when there is no value to
> doing so.  Yes, we could solve this, but it isn't worth it.  This is not
> where we want to spend our complexity and conformance budgets.
>
> An UnexpectedFrogException is both accurate (you got a value in the
> unhandled remainder) and simpler.  So it wins, because we have bigger
> fish to fry.  (Yes, I know frogs aren't fish.)
>
>
>
>
> On 8/31/2020 11:18 AM, forax at univ-mlv.fr wrote:
> >
> >     To be clear, I think the sweet spot here is:
> >
> >      - Legacy enum, string, and box (ESB) switches continue to throw
> >     NPE on null;
> >      - Total switches on enum (including the current expression
> >     switches on enum) throw ICCE on a novel value;
> >      - For new switches with remainder:
> >        - Continue to throw NPE on unhandled null remainder;
> >        - Throw UnexpectedFrogException on any other unhandled remainder.
> >
> >
> > I read this as ICCE not being good enough compare to
> > UnexpectedFrogException and i don't understand why ?
> >
> > Rémi
> >
>
>