Most common checked and unchecked Java Exceptions?

Question

As far as I understand, there is no way to find out which Exceptions a method throws without looking up the API docs one-by-one. Since that is no option, I'd like to reverse the research and ask you which are the most common Exceptions and RuntimeExceptions you've come across when dealing with

• Casting
• Arrays
• Vector, ArrayList, HashMap, etc.
• IO (File class, streams, filters, ...)
• Object Serialization
• Threads (wait(), sleep(), etc.)
• or anything else that is considered "basic Java"

I realize that this might be subjective and boring but it is for a class test and I really don't know better.

Answer 1

NullPointerException

Answer 2

Checked exceptions are easy, your editor should display the javadocs when you hover/complete the method name.

Unchecked are generally actual errors and aren't even in the javadocs more often than not. I guess the most common might be IllegalArgumentException, any method that has any possible combination of parameters that is invalid should throw it.

Answer 3

How about looking for subclasses of java.lang.exception, for example here

Personally I use 2 checked exceptions of my own TransientException for cases when a retry might work. And InvalidRequestException for validation errors.

Answer 4

NumberFormatException

Answer 5

IllegalArgumentException is one that crops up often.

Answer 6

Assume the below are java.lang unless I specify otherwise:

Casting: ClassCastException

Arrays: ArrayIndexOutOfBoundsException, NullPointerException

Collections: NullPointerException, ClassCastException (if you're not using autoboxing and you screw it up)

IO: java.io.IOException, java.io.FileNotFoundException, java.io.EOFException

Serialization: java.io.ObjectStreamException (AND ITS SUBCLASSES, which I'm too lazy to enumerate)

Threads: InterruptedException, SecurityException, IllegalThreadStateException

Potentially common to all situations: NullPointerException, IllegalArgumentException

You would do well to look at Java site's Package Summary pages. Here's one: http://java.sun.com/j2se/1.4.2/docs/api/java/io/package-summary.html

Answer 7

As Bill K says. Checked exceptions are easy. If your IDE/program editor doesn't give you an quick way to see method javadocs or signatures you need to throw it away. Seriously.

Unchecked exceptions are a different kettle of fish. But I think the best strategy with unchecked exceptions is to not try to catch them. Instead, you write you code so that it avoids throwing them in the first place. For example;

// ... not sure if 'obj' is null
if (obj != null) {
    obj.someMethod();
}
// ... not sure if 'obj' has the right type
if (obj instanceof Foo) {
    Foo foo = (Foo) obj;
}
// ... not sure if 'i' is in range
if (i >= 0 && i < array.length) {
    .... = array[i];
}

Here's why I recommend this:

• A guard test is orders of magnitude more efficient than throwing and catching an exception.
• A guard test is more readable ... less lines of code.
• If you catch an unchecked exception, you can never be sure that it happened for the reasons you think it did; for example:

    // obj might be null ...
    try {
        obj.doSomething();
    } catch (NullPointerException ex) {
        System.err.println("obj was null");  // WRONG!!!
        // the NPE could have happen inside doSomething()
    }

• If an unchecked exception is caused by a bug, you DO want a stacktrace and (depending on the application) you MAY NOT want to recover.

Obviously, you only include these "guard" checks where your understanding of the code tells you that they are necessary! So, for example if you know that 'obj' ought to be non-null and 'i' ought to be in range, it is a good idea to leave the checks out. If you leave out one test too many, you'll get an exception ... but that's good because you can then use the stacktrace to figure out why your understanding of the code was wrong, and maybe fix the underlying bug.