Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>JLS hunting:</p> <blockquote> <p>It is a compile-time error if a final variable is assigned to unless it is definitely unassigned (§16) immediately prior to the assignment.</p> </blockquote> <p>Quoth chapter 16:</p> <blockquote> <p>V is definitely unassigned before a catch block iff all of the following conditions hold: </p> <p><strong>V is definitely unassigned after the try block.</strong><br> V is definitely unassigned before every return statement that belongs to the try block.<br> V is definitely unassigned after e in every statement of the form throw e that belongs to the try block.<br> V is definitely unassigned after every assert statement that occurs in the try block.<br> V is definitely unassigned before every break statement that belongs to the try block and whose break target contains (or is) the try statement.<br> V is definitely unassigned before every continue statement that belongs to the try block and whose continue target contains the try statement. </p> </blockquote> <p>Bold is mine. After the <code>try</code> block it is unclear whether <code>i</code> is assigned.</p> <p>Furthermore in the example</p> <pre><code>final int i; try { i = foo(); bar(); } catch(Exception e) { // e might come from bar i = 1; } </code></pre> <p>The bold text is the <em>only</em> condition preventing the actual erroneous assignment <code>i=1</code> from being illegal. So this is sufficient to prove that a finer condition of "definitely unassigned" is necessary to allow the code in your original post.</p> <p>If the spec were revised to replace this condition with</p> <blockquote> <p>V is definitely unassigned after the try block, if the catch block catches an unchecked exception.<br> V is definitely unassigned before the last statement capable of throwing an exception of a type caught by the catch block, if the catch block catches an unchecked exception.</p> </blockquote> <p>Then I believe your code would be legal. (To the best of my ad-hoc analysis.)</p> <p>I submitted a JSR for this, which I expect to be ignored but I was curious to see how these are handled. Technically fax number is a required field, I hope it won't do <em>too</em> much damage if I entered +1-000-000-000 there.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload