Checked and unchecked exceptions. A clearer explanation please.

[exquisitus]

I've just been browsing through the Java tutorial which describes a
Nonruntime excption as:

"Nonruntime exceptions are exceptions that occur in code outside of the
Java runtime system. For example, exceptions that occur during I/O are
nonruntime exceptions. The compiler ensures that nonruntime exceptions
are caught or specified; thus, they are also called checked exceptions."

Later
(http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html)
the tutorial then lists the ff code:

public Object pop() throws EmptyStackException {
Object obj;

if (size == 0) {
throw new EmptyStackException();
}

obj = objectAt(SIZE - 1);
setObjectAt(SIZE - 1, null);
size--;
return obj;
}

And states: "Note that the declaration of the pop method contains a
throws clause. EmptyStackException is a checked exception"


My question is that why is EmptyStackException a checked exception (when
NullPointerException for example - is unchecked?). Surely, the
designation annot be arbitary?

Could someone please provide a simpler/less ambiguous explanation of the
logic behind Checked and Unchecked exceptions?

Many Thanks

 

[Adam Maass]

I've just been browsing through the Java tutorial which describes a
Nonruntime excption as:

"Nonruntime exceptions are exceptions that occur in code outside of the
Java runtime system. For example, exceptions that occur during I/O are
nonruntime exceptions. The compiler ensures that nonruntime exceptions are
caught or specified; thus, they are also called checked exceptions."

Later
(http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html)
the tutorial then lists the ff code:

public Object pop() throws EmptyStackException {
Object obj;

if (size == 0) {
throw new EmptyStackException();
}

obj = objectAt(SIZE - 1);
setObjectAt(SIZE - 1, null);
size--;
return obj;
}

And states: "Note that the declaration of the pop method contains a throws
clause. EmptyStackException is a checked exception"


My question is that why is EmptyStackException a checked exception (when
NullPointerException for example - is unchecked?). Surely, the designation
annot be arbitary?

Could someone please provide a simpler/less ambiguous explanation of the
logic behind Checked and Unchecked exceptions?

RuntimeException and its subclasses are unchecked exceptions. Error and its
subclasses are unchecked exceptions. All other exceptions are checked
excetpions.

-- Adam Maass

 

[HK]

And states: "Note that the declaration of the pop method contains a
throws clause. EmptyStackException is a checked exception"


My question is that why is EmptyStackException a checked exception (when
NullPointerException for example - is unchecked?). Surely, the
designation annot be arbitary?

Could someone please provide a simpler/less ambiguous explanation of the
logic behind Checked and Unchecked exceptions?

I would be interested in a definitive answer too.
Except I just noticed that your example
EmptyStackException is a wrong one. It is
derived from RuntimeException and thereby
unchecked.

In principle I would say that everthing
that is under the control of the program
should be unchecked, because it goes wrong only
in case of a bug, like NullPointerException,
EmptyStackException or IllegalArgumentException.

In contrast, there is no way to 100% avoid
I/O errors, therefore an IOException is an expected,
albeit annoying, state of the software and must
be dealt with.

However, the case is not so clear cut. Take, for
example, URISyntaxException. You could say the program
has full control, because it could check the syntax before
using the URI. But then checking would always
be done twice. First to ensure the syntax and then,
naturally, when the URI is used.
I fact URISyntaxException is a checked one.

Harald.

 

[Chris Uppal]

My question is that why is EmptyStackException a checked exception (when
NullPointerException for example - is unchecked?). Surely, the
designation annot be arbitary?

Could someone please provide a simpler/less ambiguous explanation of the
logic behind Checked and Unchecked exceptions?

I think the logic is that checked exceptions are used for situations that you
(the programmer) must expect to happen, and must therefore provide explicit
code to handle. Unchecked exceptions are for cases that you can legitimately
expect /not/ to occur in a deployed application (but may happen, may even
happen a lot, during development).

The canonical example of checked exceptions is opening a file. Obviously the
programmer is not normally in a position to ensure that the file exists before
opening it (and even if they were, then it's unlikely that they actually
/would/ have checked), so clearly the program must contain code to handle the
case where the file does not exist. Checked exceptions are used to force the
programmer to consider that case.

The canonical example of an unchecked exception is running off the edge of an
array. That should not happen in working software, and so there's little to
gain by forcing the programmer to handle the possibility (it still /is/ a
possibility, of course) explicitly.

Perhaps in some environments, for life- or mission- critical applications, it
/would/ be reasonable to force the programmer to handle such cases explicitly.
In applications where crashes are unacceptable no matter how severe the bug, or
however unlikely it may be that there /is/ a bug, out-of-bounds exceptions
might be better made checked.

The general idea is that problems that indicate /bugs/ in the program are
generally unchecked, whereas ones that reflect the generally unpredictable
nature of the execution environment at runtime are generally checked. It's not
a hard-and-fast distinction -- it is up to the judgement of the programmer to
decide which category the problem falls into (and as indicated above, the
category may depend on the application domain too).

All this is somewhat confused by the facts that (a) for many classes of problem
the most natural (default) response is to abort the application with an error
message, and (b) for many classes of problem it would simply be too big a
nuisance to force programmers to handle problems which might occur just about
anywhere. So for the cases that fall into both categories, there's an
additional pressure to make the exceptions unchecked, just to keep things
simple. Out-of-memory exceptions are an example of this. That condition is
not normally under the programmer's control, so you'd initially expect it to be
a checked exception, but that would just be too much of a pain in the arse, and
there's not normally much that one can do to recover from it (not locally to
the point where it's thrown anyway), so out-of-memory is signalled by an
unchecked exception.

I think that NullPointerException illustrates both points quite well. Using a
null reference (pointer) is normally an indication of a flaw in the program
logic, and what's more a flaw that ought to be caught and eliminated by
testing. It is /also/ a problem that could occur anywhere, and is rarely
recoverable, so that's two reasons to make it unchecked.

The example you gave of EmptyStackException is interesting. I think that
there's a good case to be made that attempting to pop an empty stack is simply
a programming error, and so that the exception should be unchecked. However it
would seem that the authors saw it in a different light, presumably arguing
that since any stack /can/ be empty, the popper of the stack should be forced
to deal with the case where it /is/ in fact empty. I don't agree with their
judgement on this.

Personally, I think that too many 'standard' exceptions are checked. One
reason is that exceptions tend to be grouped together by inheritance (for good
reasons). E.g IOException and its subclasses. The problem with that is that
checked/unchecked-ness does not naturally follow the same hierarchy -- or at
least, it /should/ not follow the hierarchy, but unfortunately in Java it
/does/ follow it. Resulting in too many exceptions being checked.

-- chris

 

[Patricia Shanahan]

exquisitus wrote:
....

My question is that why is EmptyStackException a checked
exception (when NullPointerException for example - is
unchecked?). Surely, the designation annot be arbitary?

Could someone please provide a simpler/less ambiguous
explanation of the logic behind Checked and Unchecked
exceptions?

....

There is a trade-off between making sure the programmer
plans for exceptions that may appear, and having too much
explicit exception handling code.

At one extreme, errors in JVM operations can happen
anywhere. If java.lang.InternalError had to be caught or
thrown everywhere it can happen, every single method would
have to be declared to throw it. Even if you enclosed the
body of the method in a try with a catch for it, it might
happen in the processing of the try-catch itself. "throws
InternalError" would add no information at all to the method
declaration.

Similarly, Most blocks of Java code can throw
NullPointerException. If it were checked, almost every
method would have to either catch it or be declared to throw it.

At the other extreme, you have to be using very specific
features to get, for example, a java.rmi.MarshalException.
The caller of a method may not be expecting it to be thrown.
Requiring it to be either caught or declared to be thrown in
the very few methods in which it can happen adds real
information that callers need.

The exact boundary between what should be checked and what
should be unchecked is difficult to set. Some cases are
clearly on one side or the other, but other cases, closer to
the boundary, seem quite arbitrary. I've extended
RuntimeException when I was building some infrastructure
that would be used throughout a program, and didn't want
every method to have to be declared to throw its exceptions.

Patricia