Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This is a summary of the strongest arguments in favor of the thesis that the current rules for definite assignment cannot be relaxed without breaking consistency (A), followed by my counterarguments (B):</p> <ul> <li><p><strong>A</strong>: on the bytecode level the write to the variable is not the last instruction within the try-block: for example, the last instruction will typically be a <code>goto</code> jump over the exception handling code;</p></li> <li><p><strong>B</strong>: but if the rules state that <code>i</code> is <em>definitely unassigned</em> within the catch-block, its value may not be observed. An unobservable value is as good as no value;</p></li> <li><p><strong>A</strong>: even if the compiler declares <code>i</code> as <em>definitely unassigned</em>, a debug tool could still see the value;</p></li> <li><p><strong>B</strong>: in fact, a debug tool could always access an uninitialized local variable, which will on a typical implementation have any arbitrary value. There is no essential difference between an uninitialized variable and a variable whose initialization completed abruptly after the actual write having occurred. Regardless of the special case under consideration here, the tool must always use additional metadata to know for each local variable the range of instructions where that variable is <em>definitely assigned</em> and only allow its value to be observed while execution finds itself within the range.</p></li> </ul> <h3>Final Conclusion:</h3> <p>The specification could consistently receive more fine-grained rules which would allow my posted example to compile.</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