Re: Exception questions
Rhino wrote:
I'm afraid I have some confusion about checked and unchecked exceptions.
First, am I correct in believing that a checked exception is one in whic=
h
the method signature contains the throws clause? For example:
public void myMethod(int foo) throws SuchAndSuchException { }
In other words, is the sole definition of whether an exception is checke=
d
or unchecked consist of whether it is in a throws clause in the method
signature? Or is there more to recognizing the existence of a checked
exception in existing code?
Jean-Baptiste Nizet wrote:
No, you aren't right. Runtime exceptions are exceptions which have
RuntimeException as one of their ancestor classes (i.e. which extend
RuntimeException or one of its subclasses, or one of its
subsubclasses, etc.)
Checked exceptions are all the other ones.
.... that extend 'Exception'.
Second, the Java Tutorial has a topic on the inappropriate use of unchec=
ked
exceptions -http://java.sun.com/docs/books/tutorial/essential/exceptions=
/runtime....
and basically advocates that if a given situation might be recoverable f=
or
the calling application, a checked exception should be thrown, not an
unchecked one.
That's not exactly true, and is controversial.
My rule of thumb is that unchecked exceptions are for programmer
mistakes, like 'IllegalArgumentException', and checked exceptions are
for environmental situations, like 'IOException'. People also use
unchecked exceptions when they don't want to force client calling code
to deal with them.
Checked exceptions force calling code to catch them, that's their
advantage.
Rhino wrote:
I'm revisiting some old classes that I wrote to try to make them as good=
as
I can and many of the methods in it detect bad input to the methods and
throw IllegalArgumentException. For example, one method examines a Strin=
g
representation of a year to see if that year is a leap year and throws
IllegalArgumentException if the year portion of the date is "0000" since
there never was a Year Zero. (The year 1 BC was followed immediately by =
1
AD).
However, I don't currently have a throws clause in the method signature =
and
I'm thinking I probably should. Have I got that right?
No.
You may or may not add the runtime exceptions your method might throw
in the throws clause. Usually, they're included in the throws clause
in order to be documented by javadoc.
You don't need to put unchecked exceptions in the method signature in
order to Javadoc them. Just add '@throws <unchecked exception type>'
to the Javadoc comment.
Runtime exceptions should be used to signal unrecoverable problems
(example : the database is down), or to signal programmer errors.
For example, if your method documentation (its contract) says that a
given argument must be a string with at least 3 chars, you should use
an IllegalArgumentException when it's not the case. If the class
documentation (its contract) says that the init method must be called
before any other one, you should use an IllegalStateException if it's
not the case.
But if the job of a method is to parse user-entered value in order to
validate it has a given format, it should throw a checked exception if
it's not the case, since the caller of your method can't make sure the
string is in the valid format before calluing it (it's the method's
job in the first place).
"Recoverable" is such a loose term. Most unchecked exceptions are
recoverable, e.g., if you get 'NullPointerException' you just return
'null' or call the method again with a default argument, so it's a
very useless rule of thumb to say "use runtime or checked for
[un]recoverable exceptions".
How do you recover from a missing file that is necessary for your
program? That's signaled by a checked exception ('IOException'), but
might not fit your definition of "recoverable". OTOH, it is almost
certainly environmental, not a programmer error, so a checked
exception makes sense.
Programmers of methods that call methods with checked exceptions often
pule about what a "bother" it is to have to catch them. Pooh widdoo
widdoo cwybabies, awwww. API writers (i.e., the methods' authors) put
checked exceptions in there on purpose, to force calling code to catch
them and (presumably) to recover from them. If the API writer deems
such autocracy unnecessary, they'll toss an unchecked exception and
just let the caller explode without forewarning.
So maybe the rule of thumb is, "If the caller should have prevented
the exception and you don't want to be bothered with warning them
because they should have known better, throw an unchecked exception.
If the caller cannot reasonably be expected to prevent the exception
by their own diligence, throw a checked exception." It's really up to
the API writer to choose.
--
Lew