5

I've discovered an odd dichotomy in the way Eclipse reports the "The local variable may not have been initialized" error. This error normally occurs if I declare a variable outside a try/catch block, initialize it inside the try/catch block, and then use it after the try/catch block:

Random r; try { r = new AESCounterRNG(); } catch (GeneralSecurityException e) { e.printStackTrace(); } r.nextInt(); //Error: The local variable r may not have been initialized 

This makes sense. I can avoid the error either by initializing the variable to null when I declare it, or by ensuring that the program's control flow never reaches the next statement if an exception occurs inside the try/catch block. Thus, in the case where I really can't continue executing if the variable initialization failed, I can do this:

Random r; try { r = new AESCounterRNG(); } catch (GeneralSecurityException e) { throw new RuntimeException("Initialize secure random number generator failed"); } r.nextInt(); //No error here 

However, I recently tried using System.exit to stop the program instead of a RuntimeException to make my program's console output cleaner. I would think these are equivalent because both prevent the program from continuing execution, but I discovered that Eclipse does not agree:

Random r; try { r = new AESCounterRNG(); } catch (GeneralSecurityException e) { System.err.println("Couldn't initialize secure random number generator"); System.exit(1); } r.nextInt(); //Error: The local variable r may not have been initialized 

Why does Eclipse still give me the "not initialized" error when execution could never reach r.nextInt() if an exception occurred? Is this a bug in Eclipse, or is there some way that execution could continue to r.nextInt() even after calling System.exit?

2
  • I think this is a compiler quirk more than an eclipse quirk, not that it really matters ;-) Commented Sep 22, 2012 at 18:52
  • If the compiler warning is causing problems for you, you could always add a line throw new RuntimeException("never happens"); after System.exit(1);...this will satisfy the compiler, and at runtime, execution will never reach it, so no harm done. Commented Mar 7, 2014 at 15:27

2 Answers 2

5

Good question, it also bugged me several times.

The problem is that unlike throwing an exception, just calling a method (and that's what System.exit(1); is) does generally not guarantee that the program flow stops. Sure, the documentation of System.exit() says that this method never returns normally. But while the semantics of throw are defined by the language itself, the semantics of System.exit() are just in the Javadocs.

My guess is that they just didn't bother to implement this special case yet. While there is a bug report where this topic is touched (https://bugs.eclipse.org/bugs/show_bug.cgi?id=126551, see comment 2), it is marked as "wont fix" because it seems to be too complicated.

Edit: As rlegendi pointed out, it is actually a problem of the Java compiler, not just of Eclipse. My solution so far was to just go with the plain old throw, (instead of some special throw() method) which (in anything else than a very small application) is better than System.exit() anyway.

Sign up to request clarification or add additional context in comments.

1 Comment

+1 for "while the semantics of throw are defined by the language itself, the semantics of System.exit() are just in the Javadocs."
1

This isn't a bug: in your second example it is guaranteed that r is initialized at the call site (you throw an exeption otherwise so that execution branch is closed).

In the first and third example you simply execute program code and leave r undefined. If you assign null to it either at the exception handling block or at the declaration it won't complain.

Btw it is not an Eclipse issue, it is defined by the JLS that you cannot use an uninitialized variable. Try compiling it with Java and you should get the exactly same output.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.