捕获异常 - 为什么有必要？

Question

Suppose I have this trivial piece of code, and at runtime list size is 4.

try{
    for(int i = 0; i < list.size(); i++){
        list.get(10);
    }

}catch(NullPointerException e){
        System.out.println(" exception to string :" + e.toString());
        System.out.println(" exception get class" + e.getClass());
        e.printStackTrace();
}

So the JVM will throw an index out of bounds exception, without having to implement this in the catch block.

Similarly, if the list is null, the JVM would throw a null pointer exception.

So with that said, why bother to declare an IndexOutOfBoundsException or NullPointerException at all? Why not just declare a generic Exception at the catch block ? What is the advantage and disadvantage to this approach?

Answer 1

Usually, you shouldn't catch a generic exception somewhere down in the code because it often indicates a bug in your code which you have to fix.

Some checked exceptions (like IOException) which are related to external resources are not within your control, so you should catch them and react to them, but NullPointerExceptions or IndexOutOfBoundException should be avoided by checking the object beforehand.

Answer 2

As you surely know there are basically two types of exceptions: checked and unchecked. You need to declare or catch checked exceptions but don't have to do that for unchecked ones.

So what's the difference? It often depends on who uses them but generally it's like this:

• Checked exceptions are thrown for things that are expected to go wrong eventually, eg IOException etc. - a file not being available (not existing, locked etc.) or writable isn't something that never happens and that the developer can try to prevent. Since you have to expect those things to go wrong you'll use a checked exception to either force the method signature to declare those things can go wrong or to catch the exception and handle the case.
• Unchecked exceptions are mostly used for things that can but should not go wrong. In many cases those are due to programming errors (such as NullPointerExceptions, IndexOutOfBoundExceptions etc.) or unexpected system failures (database not available etc.). You normally don't catch them explicitly since they're not expected anyways.

That being said there are situations where checked or unchecked exceptions are used for something else (eg in libraries that need to rely on being able to bubble up a multitude of exceptions and thus wrap checked exceptions un unchecked ones).

As for the catching/declaring in the signature: you'll normally want to be as explicit as possible with checked exceptions, ie you might want to handle an IOException differently than let's say an SQLException . Unchecked exceptions might be just caught and reported (eg by logging or rethrowing them) but even in those cases you might want to catch some explicitly, eg EJBException s which are thrown by EJBs and which might just be a wrapper for an actual checked exception and thus you might want to unwrap those.

A final word on NullPointerException : you'll probably never want to catch those explicitly since they shouldn't occur in the first place (either make sure nothing is null or check before accessing those things) and often there are so many things that could be null in a try-block (directly and in the methods that are called) that you'd have a hard time to implement a reasonable reaction. In those cases it's best to just catch any unhandled exception (as is done for threads anyways) and report them to the developer so they can have a look and fix the problem.

Answer 3

In order to understand why you may want to use more specific exceptions in your catch block instead of just the generic Throwable (which means EVERYTHING that can possibly go wrong), you may want to consider what it is that is going on here.

When creating software that is to be run in production for years, you need it to be very, very robust. This mean that you want your code to be able to handle any situation gracefully, and keep running even though something went wrong.

In the particular code you are showing it might very well be that it is perfectly acceptable that the list is too short (a library that occasionally misbehaves) but it is a fatal and unforeseen error if list is null.

The simplest way to differentiate is to use the way that the exception hierarchy is designed, and have different catch-blocks.

Also, if you use Java 7 or later, you can create a combined catch block using a pipe sign which allows you to retain the original exception even if the handling code is the same.