It's not a secret anymore!*
The moose likes Beginning Java and the fly likes better code for try and catch Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "better code for try and catch" Watch "better code for try and catch" New topic

better code for try and catch

Maureen Charlton
Ranch Hand

Joined: Oct 04, 2004
Posts: 218
I have the following code using the try { } and catch { } statements:

Could someone tell me if I have implemented this the best way? Expecially with the if statement in the try { }

Thanking you in advance!
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
At a quick glance it looks like a great start. The try-catch around a parseInt is a very simple and reliable way to validate a number.

Where is your input coming from? If it's a console app you might let the user try again, maybe in a loop that runs until it gets a good account number.

That particluar loop would show an error message before the user enters the first time. I'll let you figure out how to avoid that.

The "num = 9999" bit could be moved up to a constant. It's common to see something like this - all caps is a convention for constants.

public static final int ACCT_NUM_MAX = 9999;

It's easier to find in the future and other methods could include the value in prompts or instructions, eg "Enter an account number between 1 and " + ACCT_NUMBER_MAX.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Maureen Charlton
Ranch Hand

Joined: Oct 04, 2004
Posts: 218
Many thanks for your reply post

The input is coming from a TestFile at the moment so I have no need to implement a While loop as only one account number to validate. (Thanks for mentioning it though).

I particuly liked the constant value; never thought of that.

Thanks again!
Maureen Charlton
Ranch Hand

Joined: Oct 04, 2004
Posts: 218
Just another quick question:

Why would you declare a constant public static final ACCT_NUMBER_MAX?

I understand that static means ACCT_NUMBER_MAX would be that amount throughout the program and final means it can't be changed. So why both?
M Beck
Ranch Hand

Joined: Jan 14, 2005
Posts: 323
because the very phrase ACCT_NUMBER_MAX tells you something useful when you're reading the code - namely, "this means the highest account number possible" - which just plain the number itself wouldn't tell you.

also, you might be using ACCT_NUMBER_MAX in a lot of places in the code. then, if it should ever happen that you want to change it, you just need to change the definition of ACCT_NUMBER_MAX in one place, instead of chasing down each instance of the number itself and hope you catch them all.
Maureen Charlton
Ranch Hand

Joined: Oct 04, 2004
Posts: 218
M Beck, thank you for your response.

Unfortunately, I don't think my response was very clear.

I'm happy about declaring a constant.

What I'm a little vague with is declaring a constant both:

static AND final?

My understanding is static ensures the same value is used throughout.
My understanding is final ensures the value can't be changed.

So why declare a constant both i.e. static AND final?
Steven Bell
Ranch Hand

Joined: Dec 29, 2004
Posts: 1071
static only means that there is one reference per Class as instead of one reference per Instance. It does not stop you from changing the object that the reference points to. final stops you fram changing what the reference points to, but it does not stop you from modifying the contents of the reference.

Mark Vedder
Ranch Hand

Joined: Dec 17, 2003
Posts: 624

As M Beck discusses, the reason for the final is so it does not get changed in any code. Attempts to do so will result in a compile time error. As for the static, the static doesn't mean so much that it is used "throughout the program" (that would be a loose interpretation). It ultimately means that only a single instance of that variable is created in memory.

Lets say I an object MyThing, and we want to define a constant MAX_VALUE in MyThing. So I do the following:

If my program creates 1000 instances of MyThing, there will be 1000 separate int's created in memory, all holding the same value (and since they are final, none can be changed). Each will have a single reference pointer to it (the MAX_VALUE of each of the 1000 MyThing instances). This seems like a waste of memory since they are all holding the same value. If however, I change that to a static attribute:

Now, whether I create 1, 1000, or 1 million instances of MyThing, only one int is stored in memory. Therefore I am saving memory space (and I believe improving performance slightly, but I'm not sure on that.)

The other advantage of a static attribute, is I do not need to instantiate an instance of the object in order to access its value. So if somewhere else in my program I need to know the MAX_VALUE for MyThing, I can write MyThing.MAX_VALUE as in:

instead of having to go thorough the expensive process of creating an instance of the object first:

So in the above case, since we are declaring something as final, such that it will not change, and we therefore know each instance will have the same value, why not make it static to save memory, and make it available without needing to instantiate an object?

There are times where you will make an attribute static without making it final. Let's say I have an object for which I know a specific attribute will be the same for each instance of the object, but it may change (and thus is not final). For example, if I have a BankAccount class with an "interestRate" attribute. I want all instances of my BankAccount object to have the same interest rate, but that rate changes daily. If I create a non-static attribute:

When the interest rate changes, I have to change the interestRate attribute for all instances of BankAccount. If there are thousands of instance, it becomes a very expensive process and lowers performance. (Not to mention I'm using a several thousand times more memory then I need to be since they all hold the same value).

However, if I make interestRate static:

Now I can change the interest rate for all accounts, whether 1, 1000, or 1 million, in a single call:

It is much less expensive, and thus better performance, to call a method one time then to call it 10 thousand, or 1 million times.

I hope that helps you to understand static and final and why we would make the constant both static and final in your code; and when you would make something only static.
[ March 05, 2005: Message edited by: Mark Vedder ]
Maureen Charlton
Ranch Hand

Joined: Oct 04, 2004
Posts: 218
Steven Bell and Mark Vedder,

What can I say: Excellent replys.

Extreemly clear. Thank you very much!
Mark Vedder
Ranch Hand

Joined: Dec 17, 2003
Posts: 624

By the way, the book Head First Java does a great job of explaining these type of concepts. Check it out at the publisher's site (Oreilly). Note, the 2nd edtion just came out, and if you do a search at Amazon by title or author, only the 1st edition is shown. You need to search by ISBN (0-596-00920-8) to get the second edition to come up.
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Note that Bookpool has no trouble locating the correct edition.

"I'm not back." - Bill Harding, Twister
Mark Vedder
Ranch Hand

Joined: Dec 17, 2003
Posts: 624

Thanks for the link. I had not run across or heard of Bookpool before. I see their prices are a little better then Amazon's. I'll be taking a look at them in the future. I'm sure others will appreciate it as well.
I agree. Here's the link:
subject: better code for try and catch
Similar Threads
Database file reader
Sequential of 2 accounts file processing concurrently to update balance
Can't figure out why variable isn't recognized
Validation: check to see whether it is all integers