aspose file tools*
The moose likes Beginning Java and the fly likes OK back with another Exception Handeling question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "OK back with another Exception Handeling question" Watch "OK back with another Exception Handeling question" New topic
Author

OK back with another Exception Handeling question

Jason Mackie
Greenhorn

Joined: Feb 07, 2007
Posts: 17
I am also trying to declare my own exception called DivisionByZeroException. Therefore I have a class called DivisionByZeroException and in my Ratio class I added another catch statement to my try block and I am getting an error saying that my division by zero exception catch block cannot be reached. here is the code once for my exception class...


public class DivisionByZeroException extends Exception{

public DivisionByZeroException(){
super ("DivisionByZero error!");
}

public DivisionByZeroException(String message){
super(message);
}
}

____________________________________________________________________________
here is the code for my ratio class...

import java.util.*;
public class Ratio {
Scanner scan = new Scanner (System.in);
int n1, n2;
double r1;
boolean done;

public void ReturnRatio(){
do
{
done = true;
try
{
System.out.print("Please enter the first integer: ");
n1 = scan.nextInt();
System.out.print("Please enter the second integer: ");
n2 = scan.nextInt();
r1 = (double) n1 / n2;
System.out.print(r);
}

catch (InputMismatchException e)
{
scan.nextLine();
System.out.println("Please enter an Integer");
System.out.println();
done = false;
}

catch (DivisionByZeroException e)
{
scan.nextLine();
System.out.println("Please do not divide by zero");
System.out.println();
done = false;
}
}
while (!done);
}

}
Jason Mackie
Greenhorn

Joined: Feb 07, 2007
Posts: 17
the exact error i get is "Unreachable catch block for DivisionByZeroException. This exception is never thrown from the try statement body". I am wondering if it has anything to do with the warning i get in my division by zero exception class...it says "The serializable class DivisionByZeroException does not declare a static final serialVersionUID field of type long"
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
It's telling you that the code inside the try block cannot generate (throw) a DivideByZeroException. You could make it do that:

Can you fill in that line?


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
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39418
    
  28
You are obviously using an IDE if you get a warning about a serializable UID. No, that warning has nothing whatsoever to do with your exception handling. An SUID is a number which represents something like a hashcode for the whole class; if you serialize and de-serialize then the SUID allows the de-serializing class to check that what it is de-serializing is in fact from the same version of the class.

The thing about the catch clause is that it has to have an Exception thrown. Nowhere in the preceding try do you appear to say this sort of thing:-So there is no way the compiler can see of the flow of control ever reaching the catch(DivisionByZeroException e){} block. Hence "unreachable code."

There are a few other errors but nothing you can't sort out for yourself in two minutes.

CR
[ February 12, 2007: Message edited by: Campbell Ritchie ]
Prashanth Babu
Greenhorn

Joined: Nov 08, 2004
Posts: 6
Hi Jason,

The problem is nothing to do with suid.
Extend your DivisionByZeroException from either RuntimeException or to be specific ArithmeticException. This should solve your problem.

or


Regards,

Prashanth Babu.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39418
    
  28
Quoted by Prashanth Babu
Extend your DivisionByZeroException from either RuntimeException or to be specific ArithmeticException. This should solve your problem.

You are quite right that DivisionByZeroException ought to extend ArithmeticException, which is an unchecked Exception. But without an instruction to throw, any integer division will throw an ArithmeticException, which you haven't caught.

So I compiled your example and ran it with 12345, divided by 0, and guess what happened . . .

No, I won't tell you. Try it yourself. If you can't work out why, I shall tell you tomorrow.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39418
    
  28
I promised, so I had better tell you.

I got "infinity." The (double) cast converts the whole expression to floating-point arithmetic, which supports division by zero with infinity as the result.
Gavin Tranter
Ranch Hand

Joined: Jan 01, 2007
Posts: 333
Hi,
This interests me, I am personally in two minds as to teh usefulness of exception, and right now I cant remember if dividebyzero is an unchecked exception or a runtime error.

If it is a runtime error, even if you provide your own implemenation of a dividebyzeroException, isnt the error still going to be thrown at runtime and thus halt your program?
On the otherhand if it is an unchecked exception, I was always of the impression that you could, if you so wished, catch an unchecked exception rather then let the VM deal with it. As a checked exception is just one that you are forced to deal with, either by catching it, or re-throwing it, and an unchecked one is one that you are not expected to have to deal with. At least thats my understanding.

Thanks
G
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39418
    
  28
DivideByZeroException is whatever you make it. Go into the Java Tutorial and read about Exceptions, or the API specifications, and look for Exception or Throwable.

You will there find that there is an inheritance hierarchy rather like this:-
You can only "throw" or "catch" something which is a subclass of "Throwable." An "Exception" is defined as something a program might reasonably try to recover from, and an "Error" something which it can't be expected to recover from; when an "Error" occurs your program will crash whatever you do.

You will find that RuntimeException is thrown by the runtime environment whenever anything goes wrong, and the "other" Exceptions are thrown by the OS or something else which interacts with the runtime environment. The largest group of "other" Exceptions is IOException and its subclasses, but InterruptedException is one of the "other" on the right.

There are major differences between most of the subclasses of RuntimeException and the other types.
  • 1: RuntimeException and its subclasses are "unchecked" and the other Exceptions are "checked."
  • 2: Many of the subclasses of RuntimeException occur because of an error in the programming.
  • To sort out Exceptions in the following list, you will usually have to go back to the coding and find an error:-
  • NullPointerException
  • ArrayIndexOutOfBoundsException
  • ArithmeticException
  • StringIndexOutOfBoundsException
  • and most cases of IllegalArgumentException.

  • These "unchecked" Exceptions can therefore be left to their own devices and the coding checked whenever they occur. There are a few RuntimeExceptions which are worth handling, however, including
  • NumberFormatException and
  • InputMismatchException.

  • The Exceptions which do not extend RuntimeException however are regarded as "checked" and the compiler insists they be handled. You can handle them in two ways:
  • declare in the method header that it throws the Exception, or
  • catch it where you are.
  • You can of course declare that a method throws an unchecked Exception. Go into the API specifications and find the constructors for the java.awt.Color class which take three numbers as their parameters.

    There is, as far as I know, no way to convert an Exception which is checked into an unchecked Exception or vice versa.
    So, does your DivideByZeroException have to be thrown, declared or caught?
    If it extends RuntimeException (or more probably ArithmeticException), then you can declare it ("throws DivideByZeroException"), or catch it.
    If it extends Exception, then the compiler will insist you catch it, or declare a "throws" explicitly. If you declare "throws" that simply passes responsibility on to the method which calls the present method, which has to catch or re-throw the Exception.

    Note that in the case of some Exceptions (eg IllegalArgumentException in the java.awt.Color constructors), it is inappropriate to catch them in situ. It is much more appropriate to pass the Exception to the calling method and let it deal with it.

    I hope I haven't confused you with this long answer to what you thought was a simple question.

    CR
    [ February 14, 2007: Message edited by: Campbell Ritchie ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: OK back with another Exception Handeling question