NumberFormatException

[Drake Silver]

hello.
I'm wondering if anyone can help me out with my simple yet not so simple to me problem.
I have a
try
{
//my code goes here
catch(NumberFormatException ex)
{
jTxtArea.append("Cannot have a negative Number: " + ex.getMessage()+"\n");

}
}
In the try I have set up a few text fields to recieve input, among them I have a numeric input filed, meaning that the program will accept a number put into it.
I, however, want to restrict users from entering a negative value.
It works for that aspect, but if no value is entered the excpetion is Caught, if a value of 0, or 0.0 is entered, the exception is again Caught.
What am I doing wrong, All I want to do is make sure that no Number can be less than zero.

Now, I also realize that proper programming practices frown down on what I want to do.
I should not be using exceptions to catch proper program behaviour. I should be using good code.
But this is for school, so I don't have a choice.
I have to use exceptions, and I want to, it's fun.
So, can anyone help me?
thanks

[Drake Silver]

one more thing.
From reading post after post here on javaRanch, I'm led to believe that Excpetions can be named whatever you want them to tbe named.
Is that true?
Could I make NotAnImageException?
If so, how does the compiler know what kind of exception it is...by extending Excpetion, or RunTimeException?
I'm kinda confused if you already didn't know.
So, can anyone clarify this out for me too.
thanks.

[Dirk Schreckmann]

Perhaps you could parse the input number as you already are, then test whether the input number is valid (that it's not negative). If the test fails, throw an exception (perhaps a NumberFormatException).
Bigger Hint:
if (test fails)
  throw new NumberFormatException() ;

[Dirk Schreckmann]

You could define your own custom Exception class by extending an existing Exception class. Before creating such a new type of Exception, I'd recommend first trying to use an existing type.
If you'd like, we could discuss the merits of extending different types of Exceptions and why one might favor the use of a standard Exception over creating a new type.

[Drake Silver]

Thank you Dirk for the response to my post.
It might first help if I knew how many excpetions there were.
Do you know of any readily available info that talks about Exception and RunTimeException and all of their subclasses?
Also, for the numeric input field, I am using
Double.ParseDouble(jTextFiled.getText());
My problems stem from the rules I must follow.
I have to allow for a user to be able to create a new Bank Account(btw: that's the program, a bank account program) with either a zero balance or a number greater than zero balance.
NumberFormat seems to not like the number '0'.
Do you have any more hints...or did I completely miss your point?

[Dirk Schreckmann]

Do you know of any readily available info that talks about Exception and RunTimeException and all of their subclasses?
Take a look at The J2SE API Documentation. The documentation for java.lang.Exception lists all known subclasses at the top of the page, as does the documentation for java.lang.RuntimeException.

[Volodymyr Shram]

Originally posted by Dirk Schreckmann:

If you'd like, we could discuss the merits of extending different types of Exceptions and why one might favor the use of a standard Exception over creating a new type.

Hi!
So, you want to say, that it is better to use standard Exception over creating a new type (extended Exception)? Would you so kind to explain why do you think so, or start new thread for this discussion -- it's very interesting really.
Regards.

[Dirk Schreckmann]

I am using
Double.ParseDouble(jTextFiled.getText());
NumberFormat seems to not like the number '0'.

You're likely actually using Double.parseDouble( String ) . This method can handle "0" or "0.0" just fine. How is it exactly that you are having a problem in this regard?
[ November 05, 2002: Message edited by: Dirk Schreckmann ]

[Drake Silver]

Thankyou.
It's perfect, I'll have to read it a little later.
One more question, if you don't mind.
about NumberFormatExcpetion, could I use two catch{} statements to test for neg numbers, and strings?
right now, the way I've got my code, it checks the string input,if the exception is caught It returns the error: "not allowed to enter a negative value".
How would I use that same exception to also display Error:"Cannot use letters or characters of non-numeric format", if the string was infact letters...or symbols?
do you understand what I'm trying to say?

[Drake Silver]

Originally posted by Dirk Schreckmann:

You're likely actually using Double.parseDouble( String ) . This method can handle "0" or "0.0" just fine. How is it exactly that you are having a problem in this regard?
[ November 05, 2002: Message edited by: Dirk Schreckmann ]

well, the input works, the numbers are parsed and everything goes as planned.
But if in the input field I use '0', or '0.0', the NumberFormatException displays my error message.
I don't know why it does, but it catches zero as not being a number, I think...

[Dirk Schreckmann]

could I use two catch{} statements to test for neg numbers, and strings?

You could associate two catch blocks with one try block, but each catch block would have to catch different types of Exceptions.
You could have seperate try-catch blocks - one for each situation: 1. parse the number and 2. test the number's validity.
Note that for each (I think) standard Exception, at least one of the the constructors allows you to specify a String as an argument. If an Exception is created with a String passed to the constructor, then that String is available when you invoke the getMessage() method of the Exception object.
So, you could say
if (test fails)
  throw new NumberFormatException( "A new account with a negative balance cannot be created." );
I realize that you may be already familiar with some of the arguments against a design such as this one, but... well, what do you think might be a better design?
[ November 05, 2002: Message edited by: Dirk Schreckmann ]

[Dirk Schreckmann]

well, the input works, the numbers are parsed and everything goes as planned.
But if in the input field I use '0', or '0.0', the NumberFormatException displays my error message.
I don't know why it does, but it catches zero as not being a number, I think...

My mistake. I misread the class mentioned in your post.
[ November 05, 2002: Message edited by: Dirk Schreckmann ]

[Dirk Schreckmann]

Originally posted by Volodymyr Shram:

So, you want to say, that it is better to use standard Exception over creating a new type (extended Exception)? Would you so kind to explain why do you think so, or start new thread for this discussion -- it's very interesting really.

I've begun a new thread in The Intermediate Forum. Let's continue such a conversation over there...

[Drake Silver]

Originally posted by Dirk Schreckmann:
My mistake. I misread the class mentioned in your post.
[ November 05, 2002: Message edited by: Dirk Schreckmann ]

not a problem, but do you have any idea about why NumberFormatExceptions is handling 0 or 0.0 as not a number?

[Dirk Schreckmann]

NumberFormatException doesn't doing anything regarding parsing some number or String for format. It's an exception that is thrown when something else has a problem (such as NumberFormat).
What code with what input replicates the NumberFormatException condition?

[Volodymyr Shram]

Originally posted by Dirk Schreckmann:

So, you could say
if (test fails)
  throw new NumberFormatException( "A new account with a negative balance cannot be created." );
I realize that you may be already familiar with some of the arguments against a design such as this one, but... well, what do you think might be a better design?

Hi, Dirk.
Of course, it's very good practice -- to use existing Exceptions for non-intrinsic exception
situations: to use NumberFormatExceptioninstead writing new NegativeNumberFormatException class. But will you remember how do you use your standard
Exceptions for one or years after finishing your project? Will your co-workers involved to the project be agry with your design?
As for me, it is better to write new Exception class for individual needs: if you get some exception at server side and want to send it to client, just write public class ServerDatabaseException extends Exception implements java.io.Serializable; When you need send message to client with "A new account with a negative balance cannot be created." string just write NegativeNumberFormatException with incapsulated field which you can print with your error message or maintain this field data for your needs inside catch-block.
As for me, it's very handly and much clearer than to use standard exception classes for that puroses.
What do you think about?
Regards.

[Drake Silver]

//Creates new account based on user input
void jBtnNewAccnt_actionPerformed(ActionEvent e)
{
  try
  {
    //The if statement chesks for user input, and allows only certain input
    if (jTxtFAccType.getText().equals("checking") || jTxtFAccType.getText().equals("C")
        || jTxtFAccType.getText().equals("c") || jTxtFAccType.getText().equals("check"))
    
    {
       //If any of the above input(c,C,check,checking) is entered then the following is performed
       CheckingAccount cA = new CheckingAccount(jTxtFName.getText(),
                           myBank.getAccountCounter(),
                           Double.parseDouble(jTxtFAmount.getText()));
        myBankStorage.addItem(cA);
        jTxtArea.append("New Checking Account Added:"+ cA.getAccountNumber()+ "\n" +
                        "Account Owner:" + cA.getOwnerName() + "\n"
                        + "Balance: " + cA.getBalance()+ "\n");
    }
    
    else//if any of the input allowed below is entered then this If statement is performed.
    if (jTxtFAccType.getText().equals("savings") || jTxtFAccType.getText().equals("S")
           || jTxtFAccType.getText().equals("s") || jTxtFAccType.getText().equals("save"))
    {
       SavingsAccount sA = new SavingsAccount(jTxtFName.getText(),
                         myBank.getAccountCounter(),
                         Double.parseDouble(jTxtFAmount.getText()),myBank.getSavingsRate());
       myBankStorage.addItem(sA);
       jTxtArea.append("New Savings Account Added: "+ sA.getAccountNumber()+ "\n" +
                       "Account Owner: " + sA.getOwnerName() + "\n" +
                       "Balance: " + sA.getBalance() + "\n");
    }
    else//displays error message if input entered does not match criteria above
    jTxtArea.append("Enter either 'checking'/'c' or 'savings'/'s'\n");
  }
  catch(NumberFormatException ex)
  {
    jTxtArea.append("Cannot have a negative balance: " + ex.getMessage()+"\n");
  }
}

P.S
I using Jbuilder, you probably need to know that.
[ edited to preserve formatting using the [code] and [/code] UBB tags -ds ]
[ November 05, 2002: Message edited by: Dirk Schreckmann ]

[Ilja Preuss]

If you are using JDK1.4+, you might want to take a look at JFormattedTextField...

[Volodymyr Shram]

Originally posted by Dirk Schreckmann:
I've begun a new thread in The Intermediate Forum. Let's continue such a conversation over there...

ok, I will post there.

[Drake Silver]

Originally posted by Ilja Preuss:
If you are using JDK1.4+, you might want to take a look at JFormattedTextField...

huh?
what exactly is that?
Is it a method for TextFields?
How would I use it?
thanks

[Ilja Preuss]

Originally posted by Drake Silver:

huh?
what exactly is that?
Is it a method for TextFields?
How would I use it?
thanks

It's a class (therefore it starts with an uppercase letter ), more specifically a subclass of JTextfield. As far as I can tell it should be able to do most of the checking and converting for you. See http://java.sun.com/j2se/1.4.1/docs/api/javax/swing/JFormattedTextField.html

[Drake Silver]

hi, thanks for the idea, but I'm supposed to use exceptions for handling wrong input and
NumberFormat should not interpreting 0 or 0.0 as not a number.
I only really want to take text from a textfield, then if not a number, display the catch statemnt.
In a similar post I found this:
try{
int i = Integer.parseInt(args[0]);
}
catch (NumberFormatException e)
{
System.out.println("Please enter only numerics");
System.exit(0);
}
So, after all this reading I'm beginning to understand Numberformat a little more.
so..why would I use it to check for negative numbers, they are after all still numbers. Wouldn't I instead want to use If then else statements to check for negative numbers..doesn't that make more sense.

[Drake Silver]

hi, this is a mystery to me...
I've tried simplifying my code to see where the problems arise..but I can't make it any simpler..and the NumberFormat still won't accept
0, or 0.0 as numbers..
here's the code:
try
{
Double.parseDouble(jTxtFAmount.getText());
}
catch(NumberFormatException ex)
{
jTxtArea.append("The amount entered is illegal\n"+ex.getMessage()+"\n");
}
I'd just as well say, you can't have a zero balance..becuase that's what the exception keeps catching.

[Dirk Schreckmann]

So, after all this reading I'm beginning to understand Numberformat a little more.

I think there may be some confusion about what a NumberFormatException object is and what a NumberFormat object is. To be very clear - a NumberFormat object is not a NumberFormatException. I see no where in your code where you are making use of a NumberFormat object.

why would I use it to check for negative numbers, they are after all still numbers. Wouldn't I instead want to use If then else statements to check for negative numbers..doesn't that make more sense.

You wouldn't use either NumberFormat or NumberFormatException to check for a negative number. You may want to use the if (test fails) then throw new NumberFormatException( "error message" ) construct as suggested previously.
You've suggested that Double.parseDouble(jTxtFAmount.getText()); throws a NumberFormatException when you enter a 0 or 0.0 into the text field. I cannot replicate this problem nor would I expect to be able to as "0" or "0.0" are valid numbers.
I'd suggest that you remove all try-catch blocks from your program for a moment. Then run the program and input 0 or 0.0 into the text field and try to convert it (by pressing a button or whatever should happen). If a NumberFormatException does indeed occur, then an error message will be displayed to the console (which JBuilder captures in the white text area across the bottom of the IDE). If a NumberFormatException should occur, the error message will include information about what input String it tried to convert into a number and it will indicate at what line of the code the problem originated.

I'd just as well say, you can't have a zero balance..because that's what the exception keeps catching.

You should be able to parse "0" or "0.0" into a number. An exception isn't catching anything. Perhaps an exception is being created and thrown when something that tries to do something fails.

[Drake Silver]

thanyou Dirk.
I'll try what you mentioned...and sorry, I didn't know that there was NumberFormat, so I just shortened NumberFormatException into NumberFormat to type less.
I recently read about NumberFormat and realized my error here on this forum.
sorry about that.
but thanks for pointing it out.
I'll post back in a bit to update you guys with my progress.

[Drake Silver]

Geesh...
I tried commenting out everything to do with the exception, then I ran my program, tried using 0 and 0.0 as the input, and guess what.
It wouldn't work...
I got an annoying Jbuilder beep signifying that I was performing an illegal operation of some sort.

so, it isn't my exception that has the problem, but I'm guessing it's the class that I am calling that won't accept 0 or 0.0 as input.
so...I guess this answers my question.

Thankyou for all the help so far, I would've been battling this for days trying to figure it out. All along the simplest check was to simply try my program without a try...catch and see if it still didn't work properly.
Man..talk about your dissapointments
I will probably post again in a while, I'm moving ahead in the program, trying to finish it tonight.
thanks