This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Zero division Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Zero division" Watch "Zero division" New topic
Author

Zero division

Pete Low
Greenhorn

Joined: May 25, 2005
Posts: 10
Hi,

Can anyone assist what can I do if the numerator is zero ?

int dolM1 = ( diffTot / 100 ) ;

Rgds

Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
The value of dolM1 would be zero. What's wrong with that?


Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Archies Gomes
Ranch Hand

Joined: Jun 19, 2005
Posts: 34
Hi pete
There should not be any problem if the numerator is 0(untill you arent talking bout money ....hehe )...neways jokes apart. you will just get the resulting answer as zero itself.....yeah but if the denominator is a zero value then you will get an arithmatic error ....so if you are epxecting denominator as zero then better put the code in a try ..catch block to prevent the termination of your program.
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1817

Originally posted by Archies Gomes:
so if you are epxecting denominator as zero then better put the code in a try ..catch block to prevent the termination of your program.

Of, better yet, add the additional logic:



Exceptions should be exceptional; if you anticipate it, then it's not an exception. (Not only that, but throwing exceptions is extremely expensive. This is not a problem if you execute this logic one or two times, but even at one hundred times you will notice a significant impact to the application if you use exceptions to handle this instead of the if clause.


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Archies Gomes
Ranch Hand

Joined: Jun 19, 2005
Posts: 34
Hi Joel,
Whenever if you take the input from a user then we cannot anticipate what is he/she going to provide....a zero or a non zero value,So rather then testing each time whether the value inputted is 0 or not(testing does take some time,and it can be at run time and not compile time if input is provided at the run time itself)So to avoid this we can go for the try ...catch block wherein the catch block gets executed only when the input is zero.
Now consider checking for ArrayIndexOutofBounds()... shall we check by a if condition that is the range outside the size or will we put a try ....catch block around the code.

class Test
{
int items[10];
int give;
Test()
{
//Put items in array named items from a[0] to a[10]

foo();

}
public int foo()
{give=0//Default value
//Ask user which one he wants to remove
//take input from user and put in variable selected
//Now do we check whetehr selected is in range 0 to 10 or
try
{
give=items[selected];

}catch(ArrayIndexOutfBounds(Exception e){System.out.println("Sorry Wrong value so be happy with the default");}
return give;
}
public static void main(String a[])
{
new Test();

}
}
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1817

I agree that testing does take some time, but on average the testing time is very little. In addition, with testing you don't actually try to execute the code if it fails the test, thereby saving some time there.

As I say, this really doesn't matter in some (perhaps most) instances, but it is a good habit to get into to test rather than rely on exceptions. Here's a program that demonstrates relative speeds:



And here's the results. Note that they are virtually identical for small numbers, but you start to see a difference at about 1000 tests, and for the larger volumes there is a huge difference (1/2 a second vs. 2 and 1/2 minutes at the largest volume tested):

Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1817

And as for your example, that actually makes for a pretty poor user interface (no slight intended; it just is not a good design).

What you would want to do in that case is the following:



Or, even better, move the validation logic to the getInputFromUser method:


That way, you know that the userSelectedIndex is valid; there's no need to catch the exception. As a general rule, RuntimeExceptions should not be caught (there are exceptions...) A RuntimeException shows some basic flaw in the programming logic; not all pathways were considered. Catching these don't solve the root problem; they just mask it.
Archies Gomes
Ranch Hand

Joined: Jun 19, 2005
Posts: 34
Hi joel,
Its really nice of you to give such a really live example.....I really appriciate that....Thanks neways.
 
wood burning stoves
 
subject: Zero division