Code from homework assignment.  We haven't gotten to error trapping yet. 
  But I'd like to know.

int Years;
years  = Integer.parseInt(JOptionPane.showInputDialog("Enter years));

2 questions.

1)  How does one trap if something besides an integer is not entered? 
Like a blank value or an alpha string? Is it best practice to not 
Integer.parse until after on gets the input?  IOW, use a string for 
input, see if it's not null, verify it's a number (is the an IsNumeric 
test?), then convert?

2)  How does one check if the user pressed the Cancel button?  Again, 
should Integer.parseInt be excluded until after the input is checked?

Salad <oil@vinegar.com> wrote in 
news:1audnYH1uulP4jzUnZ2dnUVZ_oTinZ2d@earthlink.com:

> Code from homework assignment.  We haven't gotten to error trapping yet. 
>   But I'd like to know.
> 
> int Years;
> years  = Integer.parseInt(JOptionPane.showInputDialog("Enter years));
> 
> 2 questions.
> 
> 1)  How does one trap if something besides an integer is not entered? 
> Like a blank value or an alpha string? Is it best practice to not 
> Integer.parse until after on gets the input?  IOW, use a string for 
> input, see if it's not null, verify it's a number (is the an IsNumeric 
> test?), then convert?
> 
> 2)  How does one check if the user pressed the Cancel button?  Again, 
> should Integer.parseInt be excluded until after the input is checked?

A)
Your code will not compile as is (even if I put it in a method in a class) 
because it contains two errors.  It is always best to copy and paste 
compilable code so that your unpaid friends in this forum don't have to sort 
out your typos from your real issues.

B)
To answer #2, break your code into pieces like this:

import javax.swing.JOptionPane;

public class JOptionPaneExperiment2 {
	public static void main(String[] args) {
		String response = JOptionPane.showInputDialog("Enter years") ;
		System.out.println("Response was: "+ response) ;
		Integer.parseInt(response);
	}
}

Run it, press the cancel button, and you will see that the message 
Response was: null
is printed.
Notice that this requires knowing about System.out, which you may not have 
gotten to in your course yet.

C)
More on question #2:
If you look at the Javadocs for JOptionPane.showInputDialog, this should be 
documented but isn't.  That is, it is documented for the showInputDialog 
method that takes seven arguments that it will return null if the user 
presses cancel, but it is not documented for the one argument version.  :-(
In any case, you may not have learned in your course how to deal with null 
yet.

D)
If you look at the Javadocs for Integer.parseInt, you will see that it throws 
NumberFormatException "if the string does not contain a parsable integer."  
This allows you to find out whether the input is appropriate or not.  First, 
however, you will have to learn (if you don't know already) what an Exception 
is and how to handle it. 
 

You asked good questions, but I sense (perhaps incorrectly) that you might be 
getting ahead of yourself.  It would be a good idea to get the Javadocs (if 
you don't have them already) and learn to read them.  They are imperfect but 
a good place to start.

Ian Shef wrote:

> Salad <oil@vinegar.com> wrote in 
> news:1audnYH1uulP4jzUnZ2dnUVZ_oTinZ2d@earthlink.com:
> 
> 
>>Code from homework assignment.  We haven't gotten to error trapping yet. 
>>  But I'd like to know.
>>
>>int Years;
>>years  = Integer.parseInt(JOptionPane.showInputDialog("Enter years));
>>
>>2 questions.
>>
>>1)  How does one trap if something besides an integer is not entered? 
>>Like a blank value or an alpha string? Is it best practice to not 
>>Integer.parse until after on gets the input?  IOW, use a string for 
>>input, see if it's not null, verify it's a number (is the an IsNumeric 
>>test?), then convert?
>>
>>2)  How does one check if the user pressed the Cancel button?  Again, 
>>should Integer.parseInt be excluded until after the input is checked?
> 
> 
> A)
> Your code will not compile as is (even if I put it in a method in a class) 
> because it contains two errors.  It is always best to copy and paste 
> compilable code so that your unpaid friends in this forum don't have to sort 
> out your typos from your real issues.

I supplied a snippet.  I'll remember to provide full code in the future.

> 
> B)
> To answer #2, break your code into pieces like this:
> 
> import javax.swing.JOptionPane;
> 
> public class JOptionPaneExperiment2 {
> 	public static void main(String[] args) {
> 		String response = JOptionPane.showInputDialog("Enter years") ;
> 		System.out.println("Response was: "+ response) ;
> 		Integer.parseInt(response);
> 	}
> }
> 
> Run it, press the cancel button, and you will see that the message 
> Response was: null
> is printed.
> Notice that this requires knowing about System.out, which you may not have 
> gotten to in your course yet.

Thanks.  I figured that's what I'd have to do.  First do the input. 
Verify.  Then continue.

> 
> C)
> More on question #2:
> If you look at the Javadocs for JOptionPane.showInputDialog, this should be 
> documented but isn't.  That is, it is documented for the showInputDialog 
> method that takes seven arguments that it will return null if the user 
> presses cancel, but it is not documented for the one argument version.  :-(
> In any case, you may not have learned in your course how to deal with null 
> yet.
> 

No, we haven't.  I can set an initial value with the showInputDialog 
version I was using but not with the one that can take seven 
arguments...if I read the docs correctly.

> D)
> If you look at the Javadocs for Integer.parseInt, you will see that it throws 
> NumberFormatException "if the string does not contain a parsable integer."  
> This allows you to find out whether the input is appropriate or not.  First, 
> however, you will have to learn (if you don't know already) what an Exception 
> is and how to handle it. 
>  
I learned a slight bit on the web.  Like other languages, some common 
tasks I figure would be standard or part of the language doesn't exists 
and you need to roll your own.  In my case, there was no IsNumeric() 
Java function/method so I wrote my own and was introduced to try/catch.
> 
> You asked good questions, but I sense (perhaps incorrectly) that you might be 
> getting ahead of yourself.  It would be a good idea to get the Javadocs (if 
> you don't have them already) and learn to read them.  They are imperfect but 
> a good place to start.
> 

Yes, getting ahead.  I'm from the VB world.

Tho I use variants rarely I can see their use when you don't know what 
data type to expect.  Nothing like that in Java.

I suppose Java programmers write a lot of error trapping code.

There may be 30 or so key words in Java but one certainly has to 
remember a lot.  For example, in VB I might write Docmd. on a line and a 
dropdown list of methods for Docmd is displayed.  I figure a Java 
programmer has spent the time to memorize the docs.

If I want to test something out in VB I have a  window where I could enter
	? "Joe" & " " & "Blow"
and the computer will echo back Joe Blow.  In Java, I'd have to write a 
program to do that simple test.

Or I can set the debugger on to see what the values of variables are as 
I step thru the code and I don't see that flexibility in Java...tho it 
may exist.

Or create a method and have optional arguments...in other words have 
more arguments than what might be passed.

Lot's of things I'd like to know but don't.

Thanks for your help on my questions.

Salad <oil@vinegar.com> wrote in
news:s9mdnf1DLJTRljvUnZ2dnUVZ_u2dnZ2d@earthlink.com: 
<snip>
> Thanks.  I figured that's what I'd have to do.  First do the input. 
> Verify.  Then continue.
That is one way.  Another way would be to attempt the conversion.  If it 
succeeds, you haved the result.  If it fails, get the user to fix it.
<snip>
> No, we haven't.  I can set an initial value with the showInputDialog 
> version I was using but not with the one that can take seven 
> arguments...if I read the docs correctly.
I don't know how initial value got into this discussion.
The seven argument version takes an initial value argument, and the one 
argument version that you are using does not take an initial value 
argument.  However, this has nothing to do with returning null if the user 
clicks on the cancel button.
<snip>
> I learned a slight bit on the web.  Like other languages, some common 
> tasks I figure would be standard or part of the language doesn't exists 
> and you need to roll your own.  In my case, there was no IsNumeric() 
> Java function/method so I wrote my own and was introduced to try/catch.
If you use try/catch to catch the NumberFormatException that can be thrown 
by Integer.parseInt(...) then there is no need for IsNumeric().
However, if you must write your own, Character.isDigit(...) can help.
<snip>
> Tho I use variants rarely I can see their use when you don't know what 
> data type to expect.  Nothing like that in Java.
Some people love strongly typed languages, others don't.
> 
> I suppose Java programmers write a lot of error trapping code.
I suppose that it depends upon the circumstances.  It has been easier for 
me in Java than it was in Fortran.
> 
> There may be 30 or so key words in Java but one certainly has to 
> remember a lot.  For example, in VB I might write Docmd. on a line and a
> dropdown list of methods for Docmd is displayed.  I figure a Java 
> programmer has spent the time to memorize the docs.
There are good IDEs that will do this for you.  To name a few, there are 
Eclipse, Netbeans, and Gel (no longer being developed).
> 
> If I want to test something out in VB I have a  window where I could
> enter 
>      ? "Joe" & " " & "Blow"
> and the computer will echo back Joe Blow.  In Java, I'd have to write a 
> program to do that simple test.
I have found it easier to just write a program in an IDE.  I think that 
there may be tools to do this in Java if you search for them.  In fact, 
because the compiler is a built-in object in Java 1.6 (and up), it seems 
not too difficult to wite your own tool for this.  You would wrap the 
user's input with appropriate declarations, and then make use of 
javax.tools.ToolProvider, javax.tools.JavaCompiler and javax.tools.Tool .
See 
http://java.sun.com/mailers/techtips/corejava/2007/tt0307_static.html#1
if you want more information.
> 
> Or I can set the debugger on to see what the values of variables are as 
> I step thru the code and I don't see that flexibility in Java...tho it 
> may exist.
It is there, in the IDEs.  VB comes with the IDE, with Java you generally 
have to get the IDE separately.  An exception is when you go to 
java.sun.com and download Netbeans and Java together.
> 
> Or create a method and have optional arguments...in other words have 
> more arguments than what might be passed.
In Java, it is called variable arity or varargs.  It provides a facility 
similar to variable argument lists in C and C++.  However, it does not 
provide the VB capability of providing default values for omitted 
arguments.  In OOP, overloading and setters provide much of this capability 
already.  The Builder pattern can provide additonal capability when the 
number of arguments gets large.
> 
> Lot's of things I'd like to know but don't.
Time to get a book?  Many books?  :-)
> 
> Thanks for your help on my questions.
> 
Best wishes!