Initial variables before a try\catch block

[leroy tsruya]

Hi all!
I have a question considering a simple try\ catch block.
suppose this is my code:

import java.util.Scanner;
class TestClass
{
public static void main(String[] args) {
		Scanner input = new Scanner(System.in);
		int number;
		System.out.println("Please enter a number");
		try{
			number = input.nextInt();
		}catch(InputMismatchException ex){ System.out.println("I asked for an int value!");}
                                 int anotherNumber = number + 2;
	}
}
 

The code won't compile since the variable number may not be initialized. (it only gets value inside the try \ catch block, and therefore may not get a value at all.)
My question is, must i set number to an initialized value?
or is there another way to overcome it.
Thanks!

[Seetharaman Venkatasamy]

import java.util.Scanner;
class TestClass
{
public static void main(String[] args) {
		Scanner input = new Scanner(System.in);
		int number = 0;//try to initialize[atleast Default value] local variable where it is declared
		System.out.println("Please enter a number");
		try{
			number = input.nextInt();
                                                int anotherNumber = number + 2;
		}catch(InputMismatchException ex){ System.out.println("I asked for an int value!");}
                                // int anotherNumber = number + 2; // [b]why you want to calculate after an Exception [/b]?
	}
}
 

[Campbell Ritchie]

The problem is that fields have a default value, but local variables don't. When you declare a field, the JVM carves out enough memory space for it, and fills that space with 0s, so numbers are initialised to 0 (or 0.0), booleans to false and reference types to null. But there is no such mechanism for local variables, which are put onto a stack. To avoid the local variable simply copying whatever value was on the stack previously, the compiler insists that a local variable be initialised in every "path" through the code it is used in.

Parameters don't suffer this problem because every calling method must supply an argument with a value for every parameter.

You have "try . . . number = . . . " but if that line throws an Exception, then you might get the value for number after catch simply being whatever had been on the stack previously. That could be anything, even total nonsense. The prohibition against using un-initialised local variables is intended to avoid such errors.

[sai jyothi]

A local variable must be initialised .if not a Complietime eror occurs( int number=0) must be intialised

[leroy tsruya]

Thanks all!
I understand what you say about initializing, and it makes a lot of sense.
however, 0 is an int value.
suppose i make my previous code, a method as:

public int increase(Scanner input)
{
          int number = 0;
          try{   
            number = input.nextInt();   
        }catch(InputMismatchException ex){ System.out.println("I asked for an int value!");}   
  
        return number + 2;
}
 

suppose i initialize number to 0.
and suppose an exception occured, since someone typed a char 'x' for example.
in that case, my increase method will return 2, (0 +2) , which is an int value, but no number was actually inputted.
is there a way to not return anything? so i can be sure that a bad input was scanned?

Thanks!

[fred rosenberger]

you're code says this:

public int increase(Scanner input)

that says "This method will return an int".

so, having the method not return anything breaks what you said you'd do.

[Rob Spoor]

That's what exceptions are for.

[Ernest Friedman-Hill]

You have two choices: first, you could throw an exception (as has already been suggested.) Second, you could use a loop and try again.

[Rob Spoor]

In which case catching the exception is bad. You should use the check method instead:

while (!input.hasNextInt())
{
    input.next();
    System.out.println("I asked for an int value!");
    System.out.println("Try again");
}
int number = input.nextInt();

Don't forget that call to input.next(). There is something (unless the stream is closed) but it's not an int; input.next() takes that something away. If you don't then the next call to hasNextInt() will return false again, and again, and again.

[Seetharaman Venkatasamy]

Ernest Friedman-Hill wrote:Second, you could use a loop and try again.

Sorry! I am not getting you

[Ernest Friedman-Hill]

seetharaman venkatasamy wrote:
Sorry! I am not getting you

Rob shows a perfect example in his post.

[Seetharaman Venkatasamy]

Thanks