<p dir="ltr">I do not agree with Attila on this one. I think there is nothing "very smart" about compiler knowing can some variable be possibly/for sure uninitialized, especially in distant advents of non-null types from valhalla. I would love to see this feature in language. Moreover, this new rule may be event more loose if talking about checked exceptions: variable could possibly be initialized if and only if it's initialization at least in one execution branch happens before last call to method that throws checked exception in catch block, i.e.</p>
<p dir="ltr">// assuming "created" is a final variable<br>
try {<br>
created = iThrowIOException();<br>
// blah blah blah that does not throw IOException<br>
} catch (IOEception _) {<br>
created = false;<br>
}</p>
<p dir="ltr">In this example, the last possible operation to throw IOException happens before variable initialization, so variable is definitely unassigned.</p>
<p dir="ltr">Also note that this does not only apply to final local variables, but also to final fields assignment in constructors or static blocks.</p>
<p dir="ltr">I see this smartening of the compiler as a good step ahead in direction of making language more friendly and simultaneously flexible, without introducing any complex rules.</p>
<p dir="ltr">PS: I am currently unable to test provided code myself, but if ode would compile fine without assignment in catch block, this is a serious vulnerability because compiler let's through possibly uninitialized final variable.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2024, 23:44 Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I personally wouldn't like too much if the compiler tried to be very smart with this. The current behavior is very easy to reason about, and this proposal looks too special to me. Especially because then it raises more questions about `Thread.stop`.<div><br></div><div>Also, the way this issue is presented is not much of a concern (at least for the example code). Not making the local variable final is kinda whatever. Where this is annoying is when you want to capture the variable (mostly in a lambda). However, if that is the issue that you are trying to address, then I think this is the wrong solution to that issue. I think the real solution to the issue would be relaxing the constraint to be able to capture a local variable: We should be able to capture it, iff the variable is definitely assigned before capturing, and there is definitely no assignment after it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank" rel="noreferrer">archie.cobbs@gmail.com</a>> ezt írta (időpont: 2024. júl. 12., P, 22:24):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'd like to propose a very minor language improvement and would appreciate any feedback.<br></div><div><br></div><div>This is a true corner case, but I bet most developers have tripped over it a few times. It's easy to work around... but still... <br></div><div><br></div><div>Here's a simple example:</div><div><br></div><div><span style="font-family:monospace"> void describeMyThread(Thread thread) {<br> final String description;<br> try {<br> description = '"' + thread.getName() + "'";<br> } catch (NullPointerException e) {<br> description = "null";<br> }<br> System.out.println("the thread is " + description);<br> }</span><br></div><div><br></div><div>This doesn't compile:</div><div><br></div><div><span style="font-family:monospace"> DUTest.java:8: error: variable description might already have been assigned<br> description = "(null)";<br> ^</span><br></div><div><br></div><div>The error is a false positive: there is no way an exception can be thrown in the try block <i>after</i> <span style="font-family:monospace">description</span> is assigned, because <span style="font-family:monospace">description</span> being assigned is literally the last thing that occurs in the try block.</div><div><br></div><div>Developers intuitively know that <span style="font-family:monospace">description</span> will be DU at the start of the catch block, so the error feels surprising and makes the compiler seem less smart than it should be.<br></div><div><br></div><div>My proposal is to fix this by adding a "try/catch DU exception" to §16.2.15:</div><div><br></div><div style="margin-left:40px">V is definitely unassigned before a catch block iff all of the following are true:<br> V is definitely unassigned after the try block <b>or the try block ends with an assignment expression statement V=b and V is definitely unassigned after b</b><br> V is definitely unassigned before every return statement ...<br></div><div><br></div><div>A prototype compiler implementation is <a href="https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:TryCatchDUException" target="_blank" rel="noreferrer">here</a>.</div><div><br></div><div>Thoughts?</div><div><br></div><div>-Archie<br></div><div> </div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div></div>
</blockquote></div>
</blockquote></div>