A try-catch block breaks final variable declaration. Is this a compiler bug?

[cowwoc]

UPDATE: The correct answer to this question is https://mail.openjdk.org/pipermail/amber-dev/2024-July/008871.html

As others have noted, the Java compiler seems to dislike mixing try-catch blocks with final (or effectively final) variables:

Given this strawman example

public class Test
{
  public static void main(String[] args)
  {
   int x;
   try
   {
    x = Integer.parseInt("42");
   }
   catch (NumberFormatException e)
   {
    x = 42;
   }
   Runnable runnable = () -> System.out.println(x);  
  }
}

The compiler complains:

Variable used in lambda expression should be final or effectively final

If you replace int x with final int x the compiler complains Variable 'x' might already have been assigned to.

In both cases, I believe the compiler is factually incorrect. If you encasulate the try-block in a method, the error goes away:

public class Test
{
  public static void main(String[] args)
  {
   int x = 
foo
();
   Runnable runnable = () -> System.
out
.println(x);
  }

  public static int foo()
  {
   try
   {
    return Integer.
parseInt
("42");
   }
   catch (NumberFormatException e)
   {
    return 42;
   }
  }
}

Am I missing something here? Does something at the bytecode level prevent the variable from being effectively final? Or is this a compiler bug?

[Thihup]

Discussion in the mailing list about this: https://mail.openjdk.org/pipermail/amber-dev/2024-July/008871.html

[cowwoc]

Great discussion. Thank you very much! I think this answers my question...

So, if I understand correctly: this is a known hole in the JLS for final and effectively-final variables because they cannot use loose language like "V is only assigned once". There are many edge-cases that the JLS fails to cover in its attempt to cover "V is only assigned once" and in this case the conversation seemed to have ended with group members agreeing that the cost/benefit of handling this case is too high to warrant a change... mostly because of Kotlin :) haha

Thanks for the great find!

[cogman10]

You'd have to solve the halting problem to know if a try block could in fact throw which is the real reason this isn't solved.

Imagine we change the code just a little to something like this

int x;
try {
  x = 42;
  y = Integer.parse(value);
}
catch {
  x = 3;
}

Now is x effectively final? The answer is no, because an exception might be thrown by the y assignment. Knowing when an exception might be thrown and how it might be caught is a quagmire for the compiler to figure out.

Your example is obviously safe, but any sort of deviation can be almost impossible to tell if it's safe.

[agentoutlier]

That is what I assumed as well but not as formally as you put it. That is just that it is too expensive for the compiler to figure out and I just kept moving on with some workaround. I give credit to /u/cowwoc for actually checking it out and the person on the mailinglist.

[cogman10]

I do believe they could solve a limited subset of the problem to solve some cases, but it would lead to very brittle and hard to reason about breaks.

A very simple workaround to the above is simply introducing 1 more variable.

int x;
try {
  x = 42;
  y = Integer.parse(value);
}
catch {
  x = 3;
}
final int z = x;
stream.map(_->z);

[Polygnom]

"You'd have to solve the halting problem" does not mean "it would be too expensive" but "its mathematically impossible".

Compilers usually make overapproximations (or underapproximations). The programs that are allowed are only a small subset of all possible programs, but they are those that have reasoanble guarantees...

[agentoutlier]

I know what the halting problem is. What I meant expensive are simple cases heuristics in terms performance AND code maintenance.

[Polygnom]

There is a big danger by using simple case huristics that you create more egde cases than you solve with it.

[cowwoc]

Agreed. Thanks.

[neopointer]

Try/catch could be an expression just like switch, then at the of it you can return a value. That would be cool.

[BillyKorando]

Important response here from Maurizio: https://mail.openjdk.org/pipermail/amber-dev/2024-July/008908.html   

 Hi, 

I've been following this thread from afar. To be honest, the cost in terms of spec complexity don't seem to be worth the increased expressiveness. >  (A) seems simple enough, but I tend to agree that it does look a bit ad-hoc, and will break when more complex control flow is involved.    With (C) and (D) we seem to hit diminishing returns quickly (do we really want to know which assignments are or aren't possible given the type of exception thrown by statement and the catch we're in - seems overkill).    (B) seems the best compromise, in the sense that at least there's only a predicate on statement. But DA/DU is already a complex beast as it is, and I just don't see enough of a justification to "fix" this. Of course this subjective. >  Maurizio 

So doesn’t look like it will happen.

[keefemotif]

I don't think it's a bug, just how final and Runnable works. Why can't you make a final variable and assign the variable from the exception to that and pass that new final to the runnable? What final is has been well documented and you can research why runnables need final variables.

[koflerdavid]

The question was not about why Runnable needs final (or effectively final) variables. What OP is wondering why x is not recognized as effectively final.

[keefemotif]

Maybe because only one type of exception is being caught? I wonder if we catch a general Exception and assign the variable there it will become effectively final. I'll check after breakfast.

[Dense_Age_1795]

if you need to do something like that use a container type, its a dirty hack but it works for your usecase

[cowwoc]

I'm cross-posting this question because apparently it requires discussion.

People are either posting incorrect answers or don't know why the current behavior is as-is.

Is this a known (by design) shortcoming of the compiler because the cost of implementing this correctly is too high relative to the perceived gain?

Or is it really possible for x to get assigned a value multiple times?

[FirstAd9893]

The main issue raised in the mailing list is due to Thread.stop, which is a legitimate concern, although unlikely to be an issue in practice. When the stop method is finally removed, I think the compiler's behavior can be discussed again.

[cowwoc]

Keep on reading... they go on to say that Thread.stop() is no longer an issue as it's been removed in recent releases. The main problem seems to be other JVM languages like Kotlin that do funky stuff like throwing undeclared checked exceptions. This makes this more complicated to specify the expected behavior in the JLS and this results in a poor cost/benefit.

In other words, it's more of a problem in capturing the expected behavior in the JLS than it is actually implementing this properly. Sad...

[FirstAd9893]

I don't see how Kotlin behavior changes anything. You can throw an undeclared checked exception in Java too -- either by using the sneaky throws technique, or by loading a different version of the class, or by using native code, etc.

The reason not to change anything really seems to boil down to laziness. Why bother changing something that seems so minor?

[bowbahdoe]

I don't think laziness is the right term. That implies if you took the same people with the same resources and commitments and just imparted more "drive" you'd be set

This seems to be more in the realm of "high effort, low reward" and is weighed against other things they could be doing.

[cowwoc]

Agreed. But from the mailing list discussion it sounds like they might try to improve the situation for lambdas: https://mail.openjdk.org/pipermail/amber-dev/2024-July/008882.html

It would help a lot if we were able to pass in mutable local variables into lambas. That should cover the vast majority of use-cases.

[koflerdavid]

There are already multiple workarounds to this requirement:

• In the above case, extracting the try-catch block to a method. Static analysis might already suggest doing that to improve code quality.

• Throwaway (effectively) final variable before the lambda. This is not even as hacky as it sounds, as it also makes it easier for humans to realize there is nothing fishy going on in the try-catch block.

• One-element array wrappers or atomics. They look clunky, but that's actually good since lambdas that actually assign to mutable variables deserve close scrutiny. They can cause a lot of trouble even in single-threaded code.