Most common checked and unchecked Java Exceptions? [closed]

Answer 1

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 2

NullPointerException

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

• Casting - ClassCastException

• Arrays - ArrayIndexOutOfBoundsException

• Vector, ArrayList, HashMap, etc. - I rarely see exceptions when working with Java collections, but very occasionally ConcurrentModificationException

• IO (File class, streams, filters, …) - FileNotFoundException

• Object Serialization - ClassNotFoundException

• Threads (wait(), sleep(), etc.) - In my experience, usually threading problems manifest themselves in random ways that aren't exception specific. Having to deal with InterruptedException occupies a lot of time, though I haven't seen the exception actually thrown much.

• or anything else that is considered "basic Java" - by far the most common exception in my experience is NullPointerException.

Answer 5

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 6

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.