StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><a href="http://javahowto.blogspot.com/2007/01/variable-might-not-have-been.html?showComment=1206851400000#c1463508649088298714" rel="noreferrer">The "problem" you link to</a> seems to be describing this situation:</p> <pre><code>SomeObject so; try { // Do some work here ... so = new SomeObject(); so.DoUsefulThings(); } finally { so.CleanUp(); // Compiler error here } </code></pre> <p>The commenter's complaint is that the compiler balks at the line in the <code>finally</code> section, claiming that <code>so</code> might be uninitialized. The comment then mentions another way of writing the code, probably something like this:</p> <pre><code>// Do some work here ... SomeObject so = new SomeObject(); try { so.DoUsefulThings(); } finally { so.CleanUp(); } </code></pre> <p>The commenter is unhappy with that solution because the compiler then says that the code "must be within a try." I guess that means some of the code may raise an exception that isn't handled anymore. I'm not sure. Neither version of my code handles any exceptions, so anything exception-related in the first version should work the same in the second.</p> <p>Anyway, this second version of code is the <em>correct</em> way to write it. In the first version, the compiler's error message was correct. The <code>so</code> variable might be uninitialized. In particular, if the <code>SomeObject</code> constructor fails, <code>so</code> will not be initialized, and so it will be an error to attempt to call <code>so.CleanUp</code>. Always enter the <code>try</code> section <em>after</em> you have acquired the resource that the <code>finally</code> section finalizes.</p> <p>The <code>try</code>-<code>finally</code> block after the <code>so</code> initialization is there <em>only</em> to protect the <code>SomeObject</code> instance, to make sure it gets cleaned up no matter what else happens. If there are <em>other</em> things that need to run, but they aren't related to whether the <code>SomeObject</code> instance was property allocated, then they should go in <em>another</em> <code>try</code>-<code>finally</code> block, probably one that wraps the one I've shown.</p> <p>Requiring variables to be assigned manually before use does not lead to real problems. It only leads to minor hassles, but your code will be better for it. You'll have variables with more limited scope, and <code>try</code>-<code>finally</code> blocks that don't try to protect too much.</p> <p>If local variables had default values, then <code>so</code> in the first example would have been <code>null</code>. That wouldn't really have solved anything. Instead of getting a compile-time error in the <code>finally</code> block, you'd have a <code>NullPointerException</code> lurking there that might <em>hide</em> whatever other exception could occur in the "Do some work here" section of the code. (Or do exceptions in <code>finally</code> sections automatically chain to the previous exception? I don't remember. Even so, you'd have an extra exception in the way of the real one.)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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