RFR: JDK-8214114: Switch expressions with try-catch statements

[Maurizio Cimadamore]

Maybe I'm misreading your description, but I don't think the problem is 
that the stack must be empty; the problem is that the VM will empty the 
stack anyway, as per the spec:

(JVM 6.5 - athrow):

"The objectref must be of type reference and must refer to an object 
that is an instance of class Throwable or of a subclass of Throwable. It 
is popped from the operand stack. The objectref is then thrown by 
searching the current method (§2.6) for the first exception handler that 
matches the class of objectref, as given by the algorithm in §2.10."

So, I believe in your case the issue was that, once you were inside the 
handler, the VM got rid of the stuff that was on the stack and that had 
nothing to do with the switch expression, right?

As for the changes in the front-end, when doing lambdas we had to be 
quite creative in handling lambda parameters inside a field initializer 
context - but for a lambda was kind of possible because we could always 
fake some kind of (synthetic) method scope. So it appears you have no 
alternatives here - ugh (I'm a bit afraid that it will end up in a 
whack-a-mole exercise to find out all cases which assume that a variable 
owner must be something other than a variable).

Maurizio

On 06/12/2018 16:51, Jan Lahoda wrote:
> Hi,
>
> Switch expressions that contain try-catch statements don't work 
> currently, as the catch handlers require that the stack is empty when 
> the handler is invoked, but this may not be true when the switch 
> expression is inside an expression evaluation (and so some values are 
> already on the stack).
>
> The proposed solution is to stash the stack content to local variables 
> before "running" the switch expression, and fill the stack content 
> back when breaking out of the switch expression. This is done only if 
> the try-catch statement is present in the switch expression, as it 
> produces longer bytecode.
>
> Also, it turned out variables inside switch expressions in field 
> initializers don't work properly (as their owner is the field, not a 
> method), attempted to fix that as well.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>
> How does this look?
>
> Thanks,
>     Jan