Page 614 - Introduction to Programming with Java: A Problem Solving Approach

580 Chapter 14 Exception Handling
We’ve now finished our description of the NumberList program’s three runtime errors. Normally, when you see such errors, you should fix your code so as to avoid the runtime errors in the future. So for the NumberList program, you should add fixes for the three runtime errors. One of the chapter exercises asks you to do just that.
14.12 Using throws <exception-type> to Postpone the catch
In all of the examples so far, we’ve handled thrown exceptions locally; that is, we’ve put the try and catch
blocks in the method that contains the dangerous statement. But sometimes that’s not feasible.
Moving try and catch Blocks Back to the Calling Method
Whenit’snotfeasibletouselocaltryandcatchblocks,youcanmovethetryandcatch blocksout of the dangerous statement’s method and back to the calling method. If you do that and the dangerous state- ment throws an exception, the JVM immediately jumps out of the dangerous statement’s method and passes
5
ousstatement’smethod?Mostofthetime,youshouldputyourtryandcatch blocksinthedangerous statement’s method because that promotes modularization, which is a good thing. But sometimes it’s hard to come up with an appropriate catch block when you’re inside the dangerous statement’s method. For example, suppose you’ve written a utility method that’s called from lots of different places, and the method sometimes throws an exception.AWphean agn oexcepPtioDn iFs throEwn, hyoua’dnlikce eto rhave an error message that’s customized to the calling method. It’s hard to do that if the catch block is in the utility method. The solu- tionistomovethetryandcatch blockstothecallingmethods.
Consider another example. Suppose you’ve written a method with a non-void return type that some- times throws an exception. With a non-void return type, the compiler expects the method to return a value. But when an exception is thrown, you normally don’t want to return a value because there’s no appropriate value to return. So how can you have a non-void method and not return a value? Move the try and catch blocks to the calling method. Then when an exception is thrown, the JVM returns to the calling method without returning a value. The calling method’s try and catch blocks handle the thrown exception, most likely with an error message. Let’s see how this works in a Java program.
StudentList Program Revisited
Figure 14.15 contains a modified version of Figure 14.8’s StudentList class. The main difference is that the removeStudent method now returns the name of the student it removes. This enables the calling method to do something with the removed element.
In the removeStudent method, note the return statement. The students.remove method call attempts to remove the element at the position indicated by index. If index is less than zero or greater than the index of the last element, then the JVM throws an IndexOutOfBoundsException. In our previous StudentList class, we handled the exception locally, within the removeStudent method.
5 Actually, the jump to the calling method is not immediate if there’s a finally block below the try block(s). In that case, the JVM jumps to the finally block prior to jumping to the calling method. We describe the finally block at the end of this section.
the exception back to the try and catch blocks in the calling method. Sowhenshouldyouputtryandcatch blocksinthecallingmethodasopposedtointhedanger-