# Zero division

Pete Low
Greenhorn
Posts: 10
Hi,

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

int dolM1 = ( diffTot / 100 ) ;

Rgds

Barry Gaunt
Ranch Hand
Posts: 7729
The value of dolM1 would be zero. What's wrong with that?

Archies Gomes
Ranch Hand
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
Posts: 1840
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.

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.

Archies Gomes
Ranch Hand
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
Posts: 1840
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
Posts: 1840
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
Posts: 34
Hi joel,
Its really nice of you to give such a really live example.....I really appriciate that....Thanks neways.