 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2006Why this error of "variable might not have been initialized"?
why am I getting this error "varible temp1 might not have been initialized" and "varible temp2 might not have been initialized" Here is the method tht returns a boolean comparison result: // call in driver as t1.isLess(t2) public boolean isLess(HW_413_7_Temperature Temperature2) { float temp1, temp2; char scale1 = this.charScale; char scale2 = Temperature2.charScale; if( (scale1 == 'c' || scale1 == 'C') && (scale2 == 'f' || scale2 == 'F') ) { temp1 = this.temperature; temp2 = Float.parseFloat(Temperature2.getCelsiusTemperature() ); // need to parse back to float in order to compare } if( (scale1 == 'f' || scale1 == 'F') && (scale2 == 'c' || scale2 == 'C') ) { temp1 = Float.parseFloat(this.getCelsiusTemperature() ); // need to parse back to float in order to compare temp2 = Temperature2.temperature; } if ( ( (scale1 == 'f' || scale1 == 'F') && (scale2 == 'f' || scale2 == 'F') ) || ( (scale1 == 'c' || scale1 == 'C') && (scale2 == 'c' || scale2 == 'C') ) ) { temp1 = this.temperature; temp2 = Temperature2.temperature; } return (temp1<=temp2); } Never mind. > why am I getting this error "varible temp1 might not have been > initialized" and "varible temp2 might not have been initialized" [quoted text clipped - 36 lines] > > } If none of the if blocks are executed, neither temp1 nor temp2 will have been set. Perhaps you know that both scales are set to either 'f' or 'c', but the compiler doesn't. [..] > If none of the if blocks are executed, neither temp1 nor temp2 will have > been set. Perhaps you know that both scales are set to either 'f' or 'c', > but the compiler doesn't. Well, compiler didn't complain about similar scenarios in 2 other methods. Well, I assigned a value at declaration of local variable to please the compiler. >Well, compiler didn't complain about similar scenarios in 2 other >methods. Well, I assigned a value at declaration of local variable to >please the compiler. Instances and statics get automatically initialised to 0/null. Locals do not. If you cover all the cases with no even theoretically possibly leaks with your variable initialisation code, then the compiler knows the variable has to be initialised, and it won't complain. Those few facts should be enough to explain why only sometimes the compiler complains about uninitialised variables.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > [..] > [quoted text clipped - 6 lines] > methods. Well, I assigned a value at declaration of local variable to > please the compiler. Yes, that was the difference: the variable *did* have a value. > why am I getting this error "varible temp1 might not have been > initialized" and "varible temp2 might not have been initialized" [quoted text clipped - 36 lines] > > } I can tell you how to make this message go away: initialize the two variables. In other words, replace: float temp1, temp2; with something like this: float temp1 = 0.0f, temp2 = 0.0f; The initialization values don't have to be 0.0f; in fact, for your application you may want to avoid 0.0f as the initial value of the variables because 0 is a temperature that can actually occur in nature. Someone might think that you were actually storing a temperature of 0 F or 0 C when you only meant to initialize your variables. Perhaps -500.0f would be a better initialization value since neither -500 F or -500 C can actually occur since they are below absolute zero, the lowest possible temperature. I'm not entirely sure why Java generates this message in the first place but I long ago realized that the message is avoided by initializing all variables to _something_. I usually initialize Objects to null and numbers to zero. Someone more familiar with the internal workings of Java or the JVM may have a better idea why Java generates the message in the first place if you are concerned about that. -- Rhino >> why am I getting this error "varible temp1 might not have been >> initialized" and "varible temp2 might not have been initialized" [quoted text clipped - 63 lines] > have a better idea why Java generates the message in the first place if > you are concerned about that. It's not mysterious; the message is (for once) pretty clear. If scale1 were 'd' and scale2 were 'z', none of the if blocks would be executed, and when it came time to execute the line return (temp1<=temp2); the values of temp1 and temp2 would not have been set. This causes an error, because Java refuses to use a local variable which has not been explicitly assigned a value. If it were guaranteed that they would be set, say by chanigng the code to if ( ) // f->c { // set both variables } else if () // c->f { // set both variables } else if () // no conversion { // set both variables } else // something is wrong { // throw exception } return (temp1<=temp2); no warning would be issued. >>> why am I getting this error "varible temp1 might not have been >>> initialized" and "varible temp2 might not have been initialized" [quoted text clipped - 94 lines] > > no warning would be issued. I've used other languages where numeric variables were automatically initialized to zero if you didn't initialize them yourself. That was often quite convenient. Why doesn't Java choose to do the same thing? Is it just trying to avoid the occasional case where zero wouldn't be a good default initialization? -- Rhino On Sat, 25 Mar 2006 15:57:25 -0500, "Rhino" <no.offline.contact.please@nospam.com> wrote, quoted or indirectly quoted someone who said : >Why doesn't Java choose to do the same thing? Is it just >trying to avoid the occasional case where zero wouldn't be a good default >initialization? It is simply that 0/null is a very common value for instance variables, and that initialisation has to be done anyway to avoid random effects from uninitialised variables. Further it is too hard to track if you actually initialised a static or instance variable. For locals, 0/null is much more rarely the value you want. Nearly always you want some function of other variables. Auto zero initialisation then would just mask bugs. It is also possible to track local init to ensure it is done. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > I've used other languages where numeric variables were automatically > initialized to zero if you didn't initialize them yourself. That was often > quite convenient. Why doesn't Java choose to do the same thing? Is it just > trying to avoid the occasional case where zero wouldn't be a good default > initialization? Java does initialize fields in objects and classes to 0/false/null, but not local variables. I personally like this, since it forces the programmer to think about when a variable should be initialized and to what value, but I don't know of any definitive answer about why the Java designers chose it. >I don't know of any definitive answer about why the Java >designers chose it. It follows the rules of C++, which follow the role model of C. Why did the C designers chose it? I guess, because it would take time, which would be wasted if an initialization is not needed. Java also has inherited the behavior of int-storage locations to silently wrap instead of signaling an overflow. Possibly for similar reasons. (In C, it is faster to just pass through the implementation of the hardware processor than adding overflow checks). The question remains whether the reasons that were valid for design choices of C in the 1970s are still valid for Java today. >> I've used other languages where numeric variables were automatically >> initialized to zero if you didn't initialize them yourself. That was often [quoted text clipped - 6 lines] > think about when a variable should be initialized and to what value, but I > don't know of any definitive answer about why the Java designers chose it. Whether this was intended or not, Java's approach to local initialization and validity does a decent job of discouraging the C-originated habit of declaring every single local variable at the top of a function in favour of declaring variables exactly where they're needed. I've found this leads to clearer code, provided you don't fight with it by using dummy initializers. On Sun, 26 Mar 2006 09:41:32 GMT, Owen Jacobson <angrybaldguy@google-email-service.example.com> wrote, quoted or indirectly quoted someone who said : >Whether this was intended or not, Java's approach to local initialization >and validity does a decent job of discouraging the C-originated habit of >declaring every single local variable at the top of a function in favour >of declaring variables exactly where they're needed. I've found this >leads to clear Narrowing the scope of a variable is a gift to your future self. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >> why am I getting this error "varible temp1 might not have been >> initialized" and "varible temp2 might not have been initialized" [quoted text clipped - 53 lines] > initialization value since neither -500 F or -500 C can actually occur since > they are below absolute zero, the lowest possible temperature. It's very rarely a good idea to choose arbitrary out-of-domain values to represent 'not a real value' or 'value was not set'. (A notable exception is the result of functions like indexOf that return -1 to mean 'not found', which is a well recognised standard). You can usually avoid this situation by careful structuring of your code and/or using supplemental variable(s) with obvious meanings: e.g. a boolean variable called 'temperatureIsSet'. If you ever find yourself putting an arbitrary value into your code (with some constraint such as "is less that absolute zero in degrees kelvin") please take it as a sign that there is a better way to do things - and it is worth finding that better way! Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.