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:-
NullPointerExceptionArrayIndexOutOfBoundsExceptionArithmeticExceptionStringIndexOutOfBoundsExceptionand 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 andInputMismatchException. 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, orcatch 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 ]