exception handling, perhaps?

[Andrew Humphries]

Hey folks, this is my first post here, and I rate myself as a beginner so I will put my problem here.

I am writing a simple application that performs mathematical operations, but uses a system of menus and submenus (displayed with the System.out.println statement) to navigate between different types of operations and to select the operations themselves. The follow bit of code is standard for each menu:

try {
        // Input and parsing, using tempmenuoption as a temporary store      
        String tempmenuoption = stdin.readLine(); 
        menuoption = Integer.parseInt(tempmenuoption);
        }
        
catch (NumberFormatException e) {
        // Print error message to user
        System.out.println("ERROR: Number Format Exception; please enter an integer.");
        }

I use the NetBeans IDE because that is what I have been taught in, and it allows me to manage my projects. In 3.6 with 1.4.2 this piece of code worked fine, but I upgraded to NetBeans 4.0 with 1.5.0 (update 2) and this code doesn't work. It executes without compiler error, but as soon as it reaches the try block, it seems to just throw an exception and prints the error before ending the program completely.

Where am I going wrong?

Many thanks in advance,

Andrew Humphries

[Jeanne Boyarsky]

Andrew,
Welcome to JavaRanch!

Try including the statement:
System.out.println(tempmenuoption) before parsing the integer to see what the program thinks is being input.

[Andrew Humphries]

Thanks for the welcome. I really think, from looking around this forum and the java.sun.com forums, that these places can help me develop myself as a developer (too much developing? ).

I added the println statement as you said, and it returned an output of 'null'.

[K Riaz]

So the program is not even receiving an int to parse, so verify what you are sending to it. I'm surprised you don't get a NullPointerException.

[Andrew Humphries]

Well, it is supposed to recieve input from the user, the flow shouldn't move forward until the program has recieved some form of input. It seems to be assuming the input is 'null' or recieving input from elsewhere (netbeans?)

[Andrew Humphries]

Bump, can no one see where I'm going wrong? Why is the value 'null' being assumed, rather than an integer being read and parsed from the user?

Perhaps the construction of my Readers is at fault? I used the following code:

private static BufferedReader stdin = new BufferedReader(
                 new InputStreamReader(System.in));

[ March 13, 2005: Message edited by: Andrew Humphries ]

[Ernest Friedman-Hill]

THere's nothing wrong with your code, it just looks like your IDE is not wiring up System.in properly when you run the app. Try running it from the command line.

Remember that readLine() returns null at EOF, so you should be checking for this anyway.

[Layne Lund]

As EFH, the problem is with NetBeans not connecting the input to the console so your program to get it. While IDE's are useful tools, they can have problems dealing with console I/O. I'm just learning NetBeans 4.0 myself and don't know how it handles this, so I won't be much help there. Do you know how to run your program from the command line? If so, you should try doing it that way. If not, you should certainly learn how. IMO, learning how to use command-line tools will benefit your skills as a programmer.

Layne

[Andrew Humphries]

Aye, I can run it from the command line. I have quite a bit of CLI experience playing with *nix-based systems for a few years, and having to cope with their temperaments. GNOME under FreeBSD can be a nightmare.

I'll give it a shot and post my results. As I said, the code compiled and ran fine under NetBeans 3.6 ... I'm not sure why 4.0 would be any difference.

[Layne Lund]

From my experience with NetBeans 3.6 and 4.0, the later seems VERY different, mostly as far as project management goes. IIRC, in 3.6, you could type console input in the output window. I haven't played with console-based development in 4.0, so I don't know what differences it may have.

Layne