Prev: Simple Encrypter and Decrypter Class
Next: web service behind firewall without DNS
From: Rhino on 24 Mar 2010 11:18
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 which
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 checked
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?

Second, the Java Tutorial has a topic on the inappropriate use of unchecked
exceptions -
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html -
and basically advocates that if a given situation might be recoverable for
the calling application, a checked exception should be thrown, not an
unchecked one.

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 String
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?


--
Rhino
From: Jean-Baptiste Nizet on 24 Mar 2010 12:01
On 24 mar, 16:18, Rhino <no.offline.contact.ple...(a)example.com> 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 which
> 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 checked
> 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?
>

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.

> Second, the Java Tutorial has a topic on the inappropriate use of unchecked
> exceptions -http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime....-
> and basically advocates that if a given situation might be recoverable for
> the calling application, a checked exception should be thrown, not an
> unchecked one.
>
> 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 String
> 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?
>

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.

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).

JB.
From: Roedy Green on 24 Mar 2010 12:22
On Wed, 24 Mar 2010 15:18:04 +0000 (UTC), Rhino
<no.offline.contact.please(a)example.com> wrote, quoted or indirectly
quoted someone who said :

>In other words, is the sole definition of whether an exception is checked
>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?

see http://mindprod.com/jgloss/exception.html#TYPES
--
Roedy Green Canadian Mind Products
http://mindprod.com

Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, �How would I develop if it were my money?� I�m amazed how many theoretical arguments evaporate when faced with this question.
~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming.
From: Mike Schilling on 24 Mar 2010 13:38
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
> which 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
> checked 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?

A checked exception is a class which is a subtype of Exception but is not a
subtype of RuntimeException. If a method throws a checked exception, it
must list the execeptions's class (or a supertype thereof) in its throws
clause. It's OK to mention unchecked excpetions in the throws clause, as a
form of documentation, but it's not required.


From: Lew on 24 Mar 2010 13:51
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 which
>> 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 checked
>> 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 unchecked
>> exceptions -http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime....
>> and basically advocates that if a given situation might be recoverable for
>> 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 String
>> 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
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Simple Encrypter and Decrypter Class
Next: web service behind firewall without DNS