Thread: Conditions and 'might not have been initialized' error.

I am making a program for my Java class. after thinking I have initialized the variable known as af and making some conditions, I get the error that af might not have been initialized. What am I missing that I keep getting this error? (All other variables have been initialized and assigned). Here is a section of my script.

        double af;
 
        ...
 
        if(choice == 0){
            af = 1.0;
        }
        else if(choice == 1){
            af = 1.3;
        }
        else if(choice == 2 && (genderChar=='m'||genderChar=='M')){
            af = 1.6;
        }
        else if(choice == 2 && (genderChar=='f'||genderChar=='F')){
            af = 1.5;
        }
        else if(choice == 3 && (genderChar=='m'||genderChar=='M')){
            af = 1.7;
        }
        else if(choice == 3 && (genderChar =='f'||genderChar=='F')){
            af = 1.6;
        }
        else if(choice == 4 && (genderChar =='m'||genderChar=='M')){
            af = 2.1;
        }
        else if(choice == 4 && (genderChar =='f'||genderChar=='F')){
            af = 1.9;
        }
        else if(choice == 5 && (genderChar =='m'||genderChar=='M')){
            af = 2.4;
        }
        else if(choice == 5 && (genderChar =='f'||genderChar=='F')){
            af = 2.2;
        }
        else{
            System.out.println("Invalid Entry");
        }
 
        tdee = bmr * af;

It's doing code path analysis. There's a path through your code where you access the value of af and it may not ever have been assigned. Try walking through your code in your mind - you'll soon spot it.

Local variables should always be initialized.

double af = 0.

Solved. I forgot to mention I didn't assign af a value. So assigning 0 to it makes the output correct after all the math, thanks.

I'm glad you got working code in the end, but your solution is a "belt and braces" kludge. The compiler analyses your code to warn you of routes through your code where your variables may be used before they are initialised. All you needed to do was to assign af in your 'else' clause. By initialising it 'just in case' you assign af *twice* every time the input data is valid.

if I return a final int from a function

There's no such thing as a 'final int', only a final variable or a final method. A final method is one that cannot be overridden, not one that guarantees its return value. I'd say javac is defensibly treating methods as black boxes: your method returns *any* int, not a specific one, for the purposes of code path analysis.

initialization is not as costly as assignment so your 2x is probably inaccurate

I think this is probably only valid in older languages like COBOL with separate data / program text, in which the compiler produces an initialised 'memory image' and every variable has 'module scope'. In practically any language where variables have scope that starts with their declaration, what declaration of a variable will do is to reserve some labelled space, initialisation (setting the value in that space) being exactly the same as assignment. Besides - my '2x' refers to what the program 'says', which is indisputably assigning the variable twice for all valid inputs. It's a logical duplication.

The only way I could imagine initialisation (assignment on declaration) being a special case is in the case (this case) were a variable is being initialised to a literal which already occupies space in the program text. I have strong doubt that Java works that way - a doubt dispelling authoritative explanation will always be welcome.

I see the motivation for your rule-of-thumb: it might save a weak programmer from a weak compiler. Javac's code path analysis is good though, I think we should be encouraging new programmers to take full advantage of that kind of correctness checking, and help them right correct code rather than weak-compiler-safe code.

I was going to suggest a half-way house between 'always initialise' and 'cover all paths', but decided it's probably the worst option of all: to use a function to assign the value. That would at least cause the compiler to complain at the point the integer is being assigned: the great problem with a missed code path is that the compiler complains where the variable is first *used*. Initialisation and use could be separated by reams of code, so it's no wonder new programmers are confused.

Here's some quick code that compares what I think are the available options. There's one in there which - as far as I know - is not available, and that's the 'anonymous inline function'. I wish I could write Java like that! Does that work in any other language?

package com.javaprogrammingforums.domyhomework;
 
public class AlwaysInitialise
{
  public static void main(String[] args)
  {
    int theInt;
 
    // clearly broken, needs else
    if (Math.random() < 0.5)
      theInt = 0;
    else if (Math.random() > 0.5)
      theInt = 1;
    /* omitting the else gives 'variable theInt might not have been initialized' */
    else
      theInt = -1;
    /* */
    // compiler complains here if theInt is not initialised, which is
    // bad because use and initialisation might be greatly separated.
    System.out.println("theInt is " + theInt);
    // assign-on-initialisation and re-assign on valid inputs *sniff*
    int anotherInt = -1;
    if (Math.random() < 0.5)
      anotherInt = 0; // RE-assignment
    else if (Math.random() > 0.5)
      anotherInt = 1; // RE-assignment
    // assign with method 'missing return statement' error more obvious
    // but this method is ugly - a method that's only used once?
    int yetAnotherInt = yetAnotherIntAssignment();
    // what's ideal (I think) is an 'anonymous inline function':
    // in which even local variables can be declare to assist in 
    // the initialisation of myIdealInt, but their scope would be
    // limited here. Of course, the same effect can be obtained
    // by enclosing the first method in { }. The only putative
    // benefit is a change of compiler message from 'might not'
    // to 'missing return statement'.
    /* will not compile
    int myIdealInt = int
     {
      if (Math.random() < 0.5)
        return 0;
      else if (Math.random() > 0.5)
        return 1;
      return -1; // omit this line for 'missing return statement'
     }
    */
    // here's my second guess (first was to use java.lang.Number,
    // but there are a lot of abstract methods to implement) at
    // an inline instantiation with local error message:
    abstract class IntegerKludge
    { public abstract int intValue(); }
    int myKludgeInt = new IntegerKludge()
     {
       public int intValue()
      {
        if (Math.random() < 0.5)
          return 0;
        else if (Math.random() > 0.5)
          return 1;
        return -1; // omit this line for 'missing return statement'
      }
     }.intValue();
    // myKludgeInt is guaranteed assigned before use.
  }
  private static int yetAnotherIntAssignment()
  {
    if (Math.random() < 0.5)
      return 0;
    if (Math.random() > 0.5)
      return 1;
    return -1; // omit this line for 'missing return statement'
  }
}

why instance variables are initialized to null, but not local variables

That's a good question - my guess is that it's that way due to the expense of doing code path analysis for a class against inline code. If you declare a class with an uninitialised public member variable, javac would have to do code path analysis on the class every time it was used. Compromises are never fully satisfying for everyone!

I'd never really been conscious before that variables were initialised in classes and not in local code, and I use that declare-uninitialised, complicated-initialisation-block pattern a lot. I think I might be on auto-pilot while I'm writing local code.