Any ideas?

study this code.. maybe you can come up with something...

if(isnum(dayString)==false){

System.out.println( "Day entered is invalid." );

sValid="1";

}else{

if(dayString.length()!=2){

System.out.println( "Day entered is invalid." );

sValid="1";

}else{

if(Integer.parseInt(dayString)>12 || Integer.parseInt(dayString<1){

System.out.println( "Day entered is invalid." );

sValid="1";

}

}

}

// determine whether a string is a number

// nnn or -nnn

private static boolean isnum(String s) {

int slen = s.length();

int i = slen >= 2 && s.charAt(0) == '-' ?

1 : 0;

for (; i < slen; i++) {

if (!Character.isDigit(s.charAt(i))) {

return false;

}

}

return true;

}

lordkurta at 2007-7-12 17:32:03 >

Without seeing the error messages and all of the code that should be executing (ie the contents of the daysInMonth method) it is very difficult to say; however, I do have some questions and suggestions.

The first idea that comes to mind is a data type conflict (though I would expect this to be detected at compilation). Does the daysInMonth method return a short? If it returns a long, int, float, etc., its value must be cast to a short to be compared with the return of Short.parseShort().

Does a single press of the enter key result in multiple errors?

When errors occur in java, they will propagate up through the code until they reach a try/catch structure. (The following only officially applies to code published by sun as u can have the catch statement do anything u like) There the error is printed followed by a list of where the error occurred in each successive function. i.e. if method_a calls method_b which calls method_c which gets an error, the error message that will be printed out will include the line that method_c got the error, followed by the line that method_b got the error, followed by the line that method_a got the error, followed by the line that whatever method called method_a got the error, and so on. See the example below which is the result of passing "a" to Integer.parseInt. This is called a stack trace and it can lead to particularly long error messages especially when dealing with errors in methods called from action handlers.

Exception in thread "main" java.lang.NumberFormatException: For input string: "a"

at java.lang.NumberFormatException.forInputString(Unknown Source)

at java.lang.Integer.parseInt(Unknown Source)

at java.lang.Integer.parseInt(Unknown Source)

at Temp.myReallyUsefullFunction(Temp.java:18)

at Temp.main(Temp.java:10)

Here you can see that a NumberFormatException happened when my program called Integer.parseInt at line 18 in the function myReallyUsefullFunction and that that particular call to myReallyUsefullFunction occurred from main at line 10

I suggest you read the error message(s) and its stack trace. If you cannot draw any conclusions from it, post the message(s) along with your code, and remember to post any methods referenced in the stack trace.

Capturing your error(s)

For the sake of convenience or in the event that your output data is longer than your command prompt window you may want to capture your program's error messages or other output.

Their are two system output streams stdout and stderr as their names imply stdout is for typical output and stderr is for error related output. Earlier versions of windows (95/98/Me and I think NT and 2k as well) merged these two streams. Windows XP, some Unix emulators, and I believe all Unix and Linux OSs operate these two streams independently. In either case, the output of a program can be redirected to a file. If you are running your programs from the command line, to redirect data going to stderr on the older operating systems (this will also redirect stdout on all OSs) use

Java MyClass command line options>myOutputFile.txt

To redirect the output on OSs that support both streams use

Java MyClass command line options 2>myOutputFile.txt

For future reference u can also use < to use a file as input for stdin

Regarding the second problem u wish to solve:

Because the parser throws the NumberFormatException you can encapsulate your current code in a try/catch statement as an alternative to that mentioned in the above response. It would look something like this

try{

//your current code here

}catch(NumberFormatException ex){

dayString = String.valueOf(FIRST_OF_MONTH);

}

However if you use the previously mentioned method you will need to check that the string is a number before attempting to parse it and then bypass the parser if it is not a number. i.e.

if(isnum(dayString))

{

//your current code here

}

else

dayString = String.valueOf(FIRST_OF_MONTH);

Assuming that the day is fairly important, it's not the best idea to arbitrarily set the day to 1 in the event of an error. I would advise that you either have setDayString return a value designating whether or not there was an error, throw an exception, or set the day to a nonsensical value (ie 0 or -1) so that the rest of the program is aware that the user's data is not valid. A return value will tell the calling method if something went wrong thus allowing it deal with it (for example by asking for the user to re-enter the date). Throwing an exception will effectively force the calling method to catch the problem or execution will be halted just as it was in your case. For more information about exceptions and error handling see http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html Lastly setting the day to a nonsensical value allows the program to check the data before processing it though this of course somewhat defeats the purpose of having a method specifically intended for setting that variable.

Hope this helps

pit_viper101a at 2007-7-12 17:32:03 >