In this chapter you will learn:

Transcription

1 In this chapter you will learn: i How exception and error handling works. i To use try. throw and catch to detect. indicate and handle exceptions. respectively. 9 To use the final 1 y block to release resources. i How stack unwinding enables exceptions not caught in one scope to be caught in another scope. i How stack traces help in debugging. m How exceptions are arranged in an exception class hierarchy. i To declare new exception classes. i To create chained exceptions that maintain complete stack trace information.

2 I l lntroduction.- c m l. Exception-Handling Overview Y, 13.3 Example: Divide By Zero Without Exception Handling O 13.4 Example: Handling Arithmeti cexceptions and InputMi smatchexceptions 13.5 When to Use Exception Handling 13.6 java Exception Hierarchy 13.7 finally block 11.8 Stack Unwinding 13.0 printstacktrace. getstacktrace and getmessage Chained Exceptions 13. l i Declaring New Exception Types Preconditions and Postconditions Assertions Wrap-Up Summary 1 Terrninology 1 Self-Review Exercises 1 Answen to Sell-Review Exercises 1 Exercises I 13. i Introduction In this chapter, we introducecxcepti<iii Iiandlii~~. An encrprion is an indication of a problem 1 diat occurs during a program's execution. The name "exception" implies that the problem / occun infrequently-if the "nile" is that a statement normally executes correctly, then the, "exception to the rule" is that a problem occurs. Exception handling enahles programmers to create applications that can resolve (or handle) exceptions. In many cases, handling an exception allows a program to continue executing as if no problem had been encountered. A more swere problem could prwent a program from continuing normal execution, insread requiring it to notify the user of the problem before terminating in a controlled manner. The features presented in this chapter enable programmers to write r<ihusr and 6aiilr-ti~lrr:11ii progran15 (.e., programs that are ahle to deal with prohlems that may arise and continue execuring). The style and details of Java exception handling are based in part on the Andrew Koenig's and Bjarne Stroustmp's paper, "Exception Handling for C++ (revised)."' Error-Prevention Tip! :.! Erccption handling he@ improve aprogram i fault tolmanre. You have already been briefly introduced to exceptions in earlier chapters. In Chaprer 7 you lexned that an ArrayIndexOutOfBoundsException occurs when an attempt is made to access an element past the end of an array. Such a problem may occur if there is an "off by one" error in a for statement that manipulates an array. In Chapter 10, we introduced the ClassCastException, which occurs when an anempt is made to cast an ohject that does nor have an is-a relationship with the type specified in the cast operator. Chapter 11 briefly mentioned the NullpointerException, which occurs whenever a null reference is used where an object is expected (for example, when an attempt is made to attach a GUI component to l. Kaenig, A., and B. Srmusrrup. "Exception Handling for C++ (revised)." Pmcredingf ofthr Uenix C++ Confrrnct, pp San Francisco, April 1990.

3 640 Chapter 13 Exception Handling a Container, but the GUI component has not yet been created). You have aiso used class Scanner throughout this text, which as you will see in this chaprer aiso may cause exceptions The chapter hegins with an overview of exception-handling concepts, then demon. strates basic exception-handling techniques. We show these techniques in action by han. dling an exception that occurs when a method attempts to divide an integer by zero. Next, we introduce several classes at the top of Java's class hierarchy for exception handling. As you will see, only classes that extend Throwable (package java.lang) directly or indirectly can be used with exception handling. We then discuss the chained exception feature that was introduced in J2SE 1.4. This 6 eature allows programmers to wrap inform: ation aboui an exception that occurr ed in anotl ier exception object to provide more detailc :d informa. tion ahout aproblem in a program. Next, we discuss additional exception-han< iling.. issues. such as how tu handle exceptions that occur in a constructor. We introduce preconditions and postconditions, which users of the classes you create understand conditions that must be true when your methods are called and when those methods rerurn. Finally, we present assertions, which programmers use at development time to help debug their code. Exception-Handling Overview Programs frequently test conditions to determine how program execution should proceed Consider the following pseudocode: If'rhr prwráiny ttrsk did nnt fxxrrzrtr cnrrect/~, I'rrfirin error prorrssiq //'th~ precr//in,q tmk did not rvec~~tr correctllt Prrfirm rrror/~ror~~iriizg... In this pseudocode, we begin by performing a task: then we test whether that task executed correctly. If not, we perform error processing. Otherwise, we continue wirh the next task. Although this form of error handling works, intermixing program logic with error-handling logic can make programs difficult tu read, modify, maintain and debug-especially in large applications. Performance Tip 13.1 Ifth~potentialprobLmrm ocnrr infequently, inttrmiwingprograrn and ewor-handling l*c caz deffade apropm Ip+rmance, becaue theprogram rnurtprrform ipotrntinllyfrequent) terr ro drtermine whether rhe tark executed cowectly and the next task can brpeformed Exception handling enables programmers to remove error-handling code from the "main line" of the program's execution, improving program clarity and enhancing modifiability. Programmers can decide tu handle any exceptions they choose-al1 exceptions, al1 exceptions of a certain type or ail exceptions of a group of related types (.e., exception types that are related rhrough an inheritance hierarchy). Such flexibility reduces the likelihood that errors will be overlooked, thus making programs more robust. With programming languages that do not support exception handling, programmers ofren delay writing error-processing code or sometimes forget tu include it. This results in

4 13.3 Example: Divide By Zero Without Exception Handling 641 less tobust software products. Java enables programmers to deal with exception handling easily from the inception of a project Exarnple: Divide By Zero Without Exception Handling First we demonstrate what happens when etrors arise in an application that does not use exception handling. Figure 13.1 prompts the user fot rwo integers and passes them to method quotient, which calculates the quotient and returns an int resulr. In this exam- ; ple, we will see that exceptions are thrown (.e., the exception occurs) when a method de-! rects a problem and is unable to handle it. The first of the three sample executions in Fig shows a successhil division. In the second sample execution, rhe user enters the value 0 as the denominator. Notice thar several lines of information are displayed in response to this invalid input. This informarion is known as the stack trace, which includes the nameoftheexception (java.lang.ari thmeticexception) in a descriptive message that indicates the problem that occurred and the, complete method-cal1 stack (.e., rhe call chain) at the time the exception occurred. The 1 stack trace includes rhe path of execution that led co the exception method by rnethnd. This information helps in debugging a program. The first line specifies that an ArithmeticEx- ception has occurred. The text after the name of the exception, "/ i by zero", indicates that this exception occurred as a resulr of an attempt to divide by zero. Java does not allow division by zero in integer arithmetic. [Note: Java does allow division by zero with floating-point 1 values. Such a calcularion results in the value infinity, which is represented in Java as a floating-point value (but actually displays as the string infini ty).] When division by zero in integer arithrnetic occurs, Java throws an ArithmeticException. ArithmeticExceptions can arise from a number of diffetent problems in arithmetic, so the extra data ("/ by zero") gives us mote information about this specific exception. Starting from rhe last line of the stack trace, we see that the exception was detected in line 22 of method mai n. Each line of the stack trace contains the class name and method (DivideByZeroNoExceptionHand1ing.main) followed by the file name and line number (DivideByZeroNoExceptionHandl ing. java: 22). Moving up the stack trace, we see that the exception occurs in line 10, in method quotient. The tnp row of the call chain indicates the tlirow point-the initial pnint at which the exception occurs. The throw point ofthis exception is in line 10 of method quotient. In [he third execution, the user enters the string "hello" as the denominatot. Notice again that astack trace is displayed. This informs us that an InputMismatchException has occurred (package java. uti 1). Our prior examples that read numeric values from the user assumed that the user would input a proper integer value. However, users sometimes make mistakes and input noninteger values. An InputMismatchException occurs when Scanner method nextint receives a string that does not representa valid integer. Staning from the end of the stack trace, we see that the exception was detected in line 20 of method main. Moving up the stack trace, we see that the exception occurs in method nextint. Notice rhat in place of the file name and line number, we are provided with the text Unknown Source. This means that the JVM does not have access to the source code for whete the exception occurred. Notice that in the sample executions of Fig when exceptions occur and stack traces are displayed, the program also exits. This dues nor always occut in Java-sometimes

5 ~~. ~~ Este material es proporcionado al alumno con fines educactivos, para la crítica y la investigación respetando la reglamentación en materia de derechos de autor. 642 Chapter 13 Exception Handling,,... - import java. util.scanner; '> { publi c class DivideByZeroNoExceptionHandli ng,.il..'l,,..,l.'!>l-í,..,i "ii,,.>! t. - public static int quotient( int numerator, int denominator ) I.,, return numerator / denominator: // possible division by zero..,* ;,, 1.',..., I.,: public static void main( String args[l ) 1 I, S,,,,, I', Scanner scanner = new Scanner( System.in );. - : i ' t i.-. System.out.print( ''Pl-.isc~ rntp:- an intrger nii~nrr~l-til-: " );, R int numerator = scanner.nextint0; System.out.print( ' P 1i.a~~ ente, an inti?qrr rlenominal-or: " ); 70 int denominator = scanner.nextinto: 2. ~ -* int result = quotientc numerator, denominator 1: -3 System.out.printf( -,: R l : "'i! I :d = "d\n". numerator, denominator, result );.-, },,mi.ii :,. :', },>,?CI, 1<,,5 :~;,~,<l~?.":'*~r,<,b;,,l,~ CG!! ;,>4,lI3.,7~!1, v?ci -... ~ ~ ~~.. ~ Please enter an integer numerator: 100 Please enter an integer denominator: 7 Result: 100 / 7 = 14 Please enter an integer numerator: 100 Please enter an integer denominator: O Exceotion i n thread "main" iava.1ana.arithmeticexceotion: / bv zero Please enter an integer numerator: 100 Please enter an integer denomi nator: he110 Exceotion in thread "main" iava.util.inoutmismatchexceotion at java.mil.scanne;. throw~or(~nknown Source) at java.util.scanner.next(unknown Source) at iava.uti1.scanner.nextint(unknown Source) ar ;ava.ur~l.scanner.nextint(ln*nown Source) at DivideByZerohoExceptionHandling.main(DivideByZero~oExceptionnandling. java:20) -~.. ~- - -.~ ~~ Fig lnteger division without exception handling. ~-p~ ~~....~- --~-- ~-~.

6 13.4 ArithmeticExceptions and InputMismatchExceptions 643 a program may continue wen though an exception has occurred and a stack trace has heen printed. In such cases, the application may produce unexpected results. The next section demonstrates how to handle these exceptions and keep the program mnning successhilly. In Fig both types of exceptions were detected in method main. In the next example, we will see how to handle these exceptions to enable the program to mn to normal completion Example: Handling A ri thmeti cexceptions and InputMi smatchexceptions The application in Fig. 13.2, which is hased on Fig. 13.1, uses exception handling to process any ArithmeticExceptions and InputMistmatchExceptions that might arise. The application still prompts the user for rwo integers and passes them to method quoti ent, which calculates the quotient and returns an i n t result. This version of the application uses exception handling so that if the user makes a mistake, the program catches and Iiandles (.e., deals with) the exception-in this case, dlowing the user ro try to enter the input again. The first sample execution iu Fig shows a successful execution that does nor encounrer any prohlems. In the second execution, the user enters a zero denominator and an ArithmeticException exception occurs. In the third execution, the user enters the string "hello" as thedenominator, andan InputMismatchException occurs. For both exceptions, he user is informed of their mistake and asked to try again, then is prompted for two new integen. In each sample execution, the program runs successfully to completion. 1., r i i r,.,:i ;,"N i,..il.i. i 1%.; 2 >.".,,.,I-:i.n 1, 4 1,!'.l. ',l,.,,i~!,\- ;.", import java.u import java.util.scanner; 5 6 public class DivideByZeroWithExceptionHandl ing 7 { 8 ir!..' '.'<'!I+,'" L.17il.l i il\.,.:. -, -*. -. :, 9 10 PU ent( int numerator, int denominator ) throws ArithmeticException return numerator / denominator; 3 ].,,,...,..:,,,..:,. iio.' ;ii r. di. i :.! n ib. i, : public static void main( String args[] ) 16 { 17 Scanner scanner = new Scanner( System.in ); c,:3r,~-:7,,!<>!-,!?p:t 18 boolean continueloop = true; :.. iii,~ i f l ~ ~ inp~!t o ~ - i ~ i. iieiirir<l do 21 { 22 try :.+a<) *'::o nc.>mh-rs?p,i ~.3lc~:l?!~n OII"!I~?~I: 21 { System.out.print( "Please entrr an inreqer numeraror: " ); int numerator = scanner.nextint(); 26 System.out.print( "Ploase i'iit~:' a11 inteq~r il~nominator: " ); Fig Handling ArithmeticExceptions and InputMismatchExceptions. (Part I of 2.)

7 ~~ ~ ~~- ~ - - Este material es proporcionado al alumno con fines educactivos, para la crítica y la investigación respetando la reglamentación en materia de derechos de autor. 644 Chapter 13 Exception Handling 1 int denominator = scanner.nextint0; i nt resul t = quotient( numerator, denominator ); System.out.printf( "\nresult: "id j!:.c! = -,d\n'', numerator, denomi nator, resul t ) ; continueloop = false; : t 1 : rn<i inoii?na } C.,.". catch ( InputMismatchException inputmismatchexception ) { System.err.printf( "\nexception: ":s\n", inputmismatchexception ) ; scanner.nextline();. iiicr?~-d iii!?u+ io uíer cdn trv au.iiri System.out.println( 'vou muír enter inteoers. Please trv ~aain.\n" 1: } enr! < a+cli catch ( ArithmeticException arithmeticexception ) r System.err. printf ( "\nfxteption: Fs\n", arithmeticexception 1; System.out.println(,, - ieio ii an invalid denominator. P1ea.e trv aqain.:n" ); },m,',l.,+ci,!' } while ( continueloop ); ;' s,,i,i rln...ahilr }.f,,l ',,,,7,~, i } i i,i- 1 3 ;,~iiir,r.',~r<iai fiii~<rpriiiiih,~nili inii Please enter an integer numerator: 100 Please enter an integer denominator: 7 Result: 100 / 7 = 14 Please enter an integer numerator: 100 Please enter an integer denominator: O Exception: java.1ang.arithmeticexception: / by zero Zero is an invalid denominator. Please try again. Please enter an integer numerator: 100 Please enter an integer denominator: 7 Result: 100 / 7 = 14 ~. ~. -p- Please enter an integer numerator: 100 Please enter an integer denominator: he110 Exception: java. util.inputmi smatchexception You must enter integers. Please try again. Please enter an integer numerator: 100 Please enter an integer denominator: 7 Result: 100 / 7 = m -- ~~~ 1 1 Fig Handling ArithmeticException~ and InputMismatchExceptions (Part 2 of 2 ) -

8

9 646 Chapter 13 Exception Handling Because an InputMi smatchexcepti on occurred, the cal1 to method nextint never successhlly read in the user's data-so we read rhat input wirh a cal1 to rnethod nextline. We do not do anyrhing with the input at this point, because we know that it is invalid. Each catch block displays an error message and asks the user to try again. Afrer either catch block terminates, the user ir prornpted for input. We will soon take a deeper look at how this flow of control works in exception handling. Common Pro~ramming Errar 13.1 Ir ir a ryntnw mor tophce code between a try block and rn rorrerpondrng catch blockr Cornmon Programrning Error 13.2 Earh ca tch block can have only a singkparameter-rptctbinga comma-separatrd lirt of excrptionparameterr ir a ryntdx ewor. m Cnrnrnon Procrarnminr Error 13.3 It i.a compilarion error to ratch therumr type in m dzfftrent catch blocks in a ringle tryrtatf- An uncaucht e~crption is an exception that occurs for which there are no matching catch blocks. You saw uncaught exceptions in the second and rhird outpurs of Fig Recall that when exceptions occurred in that example, the application terminared early (after displaying the exception's stack trace). This does not always occur as a result of uncaught exceptions. As you will learn in Chapter 23, Java uses a multithreaded model of progtam execution. Each rlirea~l is a parailel activity. One program can have rnany threads. If a program has only one thread, an uncaught exception will cause the program to terminace. If a program has multiple threads, an uncaught exception will terminare only the thread where the exception occurred. In such programs, howwer, cenain threads may rely on orhers and ifone thread terminates due to an uncaught exception. there may be adverse effects to the test of the program. Termination Model of fiception Handling Ifan exception occurs in a try block (such as an InputMismatchException being thrown as a result of the code at line 25 of Fig. 13.2), the try block terminates irnrnediately and program control transfers to the first ofthe following catch blocks in which the exception parameter's rype marches the type of the thrown exception. In Fig. 13.2, the first catch block catches InputMi smatchexceptions (which occur if invalid input is entered) and the second catch block carches Ari thmeticexceptions (which occur ifan atternpt is made to divide by zero). After the exception is handled, prograrn control does not return to the throw point because the try block has expired (which also causes any of its local variables to be lost). Rather control resumes after the lasr catch block. This is known as the tcriiiiniition niodcl ol ncipiioti haiidlinc. [Note: Some languages use the reciimlition model of csceptioii Iiandliii~, in which, after an exception is handled, control resumes just after rhe throw point.] Common rroeramming trror I Lo+ error, cm ocrur ifynu asume that afier an rxreption ir handled, control will rtturn to the Frrt rtntment after thr throwpoint..

10 13.4 Ari thmeti ~Exceptions and InputMi srnatchexceptions 647 l 1 Q Error-Prevention fin 12.2 Wirh rxception handling, a program can continur ex~mting (rather than tenninatinp) aftrr dealing with aproblem. Thir he@ ensure thc kind ofroburrapplications thatcontribute tn whar ii called mirxion-critica1 computing or burinerf-critica1 computing Notice that we name our exception parameters (inputmismatchexception and arithmeticexception) based on their type. Java programmers often simply use the letter e as the name of their exception parameters. Cood Programming Practice 13.1 Uring an rxreprion parameter name that rejccti the parameteri qpeprornoter clariq by rernindin~ theprogrammer of thc ívpc of exceptinn bein~ handled. Afrer executing a catch block, chis program's flow of control proceeds to the first statement after the last catch block (line 48 in this case). The condition in the do...whi 1 e statement is true (variable continueloop contains its initial value of true). so control returns to the beginning of the loop and the "ser is once again prompted for input. This control statement will loop until valid input is entered. At that point, program control reaches line 32 which assigns false to variable continueloop. The try block then rerminates. If no exceptions are thrown in the try block, the catch blocks are skipped and control continues with the first statement after [he catch blocks (or after the finally block, ifone is present). Now the condition for the do...whi 1 e loop is fa1 se, and method mai n ends. The try block and its corresponding catch andlor finally blocks together form a try statemciit. It is important not to confuse the terms "try block and "try srate- mentn-the term "try block" refers to the keyword try followed by a hlock of code, while the term "try starement" includes the try block, as well as the following catch block, andior fi nall y block. As with any other hlock ofcode, when a try block terminates, local variables declared in the block go out of scope (and are destroyed). When a catch block terminates. local variables declared within the catch block (including the exception parameter of that catch hlock) also go out of scope and are destroyed. Any remaining catch blocks in the try statement are ignored and execution resumes at the first line of code after the try... catch sequence-this will be a finally block, ifone is present. üsing the throws Clame Now let us examine method quotient (lines 9-13). The portion of tbe method declarationlocated at line 10 is known as a throws claiisr. Athrows clausespecifies the exceptions the method throws. This clause appears after the method's parameter list and before the method's body. The clause contains a comma-separated list of the exceptions that the method will throw if a problem occurs. Such exceptions may be thrown by statements in the method's body or by methods called in the body. A method can throw exceptions of he classes listed in its throws clause or of their subclasses. We have added the throws clause ro chis application to indicate to the rest ofthe program that this method may throw an ArithmeticException. Clienrs of method quotient are thus informed that the method may throw an Ari thmeticexception and that the exception should he caught. You will learn more about the throws clause in Section 13.6.

11 7 648 Chapter 13 Exception Frrnr-?rrevention Ti0 l j.3 -~ lfvnu know rhrit a method mifht throtu an rxcfption, include appropriate txrcption-handling codr in yoruprogram to make ir mor? Error-prevrntion Tip Rrad thr onlinc API dorurncnrationfor a mcththod bcfort uing that method in nprogram. The dorrimenratinn sptcijies th~ exceptionr rhrorun by rhe merhod (fany) and indicater rearom uhy rurh e.~ceptionr may ocmr. Thenprovid~for handling thnrr ~wreptinnr in ynurprogram. 69- Error-Preventiol Ti[r 13.5 Rerrd thr onlinp API dorurn~nrationfor an pxccption c h bifore ioriting excqtion-handling codefor that qpe of exception. The documrntarir>nfor an twreption clrrri iypicalíy containipo- r~ntial rearonr rhat rurh cxception~ occur duringprogram nrcution. When line 12 executes. if rhe denominator is zero, the JVM throws an ArithmethicException object. This object will be caught by the catch block at lines 4247, which displays basic information about the exceprion by implicitly invoking the exception's tostring method, then asks the user to rry again. If the denominator is not zero, method quotient performs the division and returns the result to the point of invocation ofmethod quotient in the try block (line 29). Lines display the result ofthe calculation and line 32 sets continueloop to false. In this case, the try block completes successhlly, so the program skips the catch blocks, fails rhe condition at line 48 and method main completes execution normallv. Note rhat when quotient throws an ArithmeticException, quotient terminates and does not return a value, and quotient's local variables go out of scope (and the variables are destroyed). If quotient contained local variables that were references to objects and there are no other references to those object, would be marked for garbage collection. Also. when an exception occurs, the try block from which quotient was called terminates before lines can execute. Here, too, if local variables were created in the try block prior to the exception being thrown, these variables would go out of scope. If an InputMismatchException is generated by lines 25 or 27, the try block terminates and execution continues with the catch block at lines In this case, method quotient is not called. Then method main continues after the last catch block (line 48). '.. When to Use Exception Handling Exception handling is designed to process synclirnnous crrors, which occur when a statement executes. Common examples we will see throughout the book are out-of-range array indices, arithmetic overflow (.e., a value outside the representable range of values), division by zero. invalid method parameters, thread interruption and unsuccesshil memory allocation (due to lack of memory). Exception handling is not designed to process problems associated with asynchrono~ir cvents (e.g., disk 110 completions, network message arrivals. mouse clicks and keystrokes), which occur in parallel with, and independent of, the program's flow of control. Software Engineerin~ Observation 13.2 ~. -- Incorporareyour exrrption-handlingitrat~gy intoyouriyrtemfrom the de-signprocerr j incqtion. Inclua'ing effectiue excrption handlinf a$er a ryrrem hai bem impl<mrnted can be dzficulr. -

12

13 650 Chapter 13 Exception Handling Y exceptional situations that can occur in a Java program and that can be caught by the application. Class Error and its subclasses (e.& OutOfMemoryError) represenr ahnormal situations that could happen in the JVM. Errors happen infrequently and should not be caught by applications-it is usually not possible for applications to recover from Errors. [Note: The Java exception hierarchy is enormous, containing hundreds of classes. Information about Java's exception classes can he found throughout [he Java API. The documentation for class Throwable can be found at java. sun.com/jzse/s.o/docs/api/java/ lang/throwable.html. From rhere, you can look at this class's subclasses to get more information ahout Java's Exceptions and Errors.] Java distinguishes between two categories of exceptions: chrcked exceptions and iincliccked esccpti<ii>. This distinction is important, because the Java compiler enforces a catcli-or-decl:ire requirernent for checked exceptions. An exception's type determines whether the exception is checked or unchecked. Al1 exception types that are director indirect subclasses of class RuntimeException (package java. 1 ang) are unchecked exceptions. This includes exceptions you have seen already, such as ArrayIndexOutOfBoundsExceptions and ArithmeticExceptions (shown in Fig. 13.3). All classes that inherir from class Exception but not class RuntimeException are considered to be checked exceptions. Clases that inherit from clas Error are considered to be unchecked. The compiler checkr each method cal1 and merhod declararion to determine whether the method throws checked exceptions. If so, the compiler ensures that the checked exception is caught or is declared in a throws clause. Recall from Section 13.4 thar the throws clause specifies rhe exceptions a method throws. Such exceprions are not caught in he method's body. To satisfy the catch part of the catch-or-declare requirement, the code that generates the exception musr he wrapped in a try block and must provide a catch handler for the checked-exceprion rype (or one of its superclass types). To satisfy the declare part of the catch-or-declare requirement, the method containing the code that generates the exception must provide a throws clause conraining rhe checked-exceprion rype after irs parameter lisr and before its method body. If the catch-or-declare requirement is not satisfied, the compiler will issue an error message indicating that [he exception must be caught or dedared. This forces progrmmers to think about the problems that may occur when a method that throws checked exceptions is called. Exception clases are defined to be checked when they are consider important enough to catch or declare. B Software En~in~ering Observation 13.6 Programmen areforced to dtal wirh chtcked exceptiom. Thir rerults in more robwr codi rhan would be creared ifprogrammerr wtre ablr ro simply ignore the cxcqptionr. m Common Programming Error 13.5 A compilahon error occurr f a method explicitly attemptr to throw a cherked exception (or callr anorher methodthat throma checkcd mception) andthatexcqption ir not lirtrd in thnt methodj throws cl?uie. Cornrnon Programrning Error 13.6 IfB rubchrr method ovemdm a iuperclarr method, ir ii an errorfor the mbch mcthod to lirt more mctptionr in itr throws clawe than the ovewiddpn ruperch~ method he,. Howevrr, a ruhclarr j throws rlaurc can conrain a rubrer ofa ruperch~j throws lit.

14 13.6 Java Exception Hierarchy 651 Softw~r? Fnr'rr~~riny Obccrv?tion fiour mcthod calis other methodi that explicirly throw checkedexc~ptioni, thox rxceptionr murt be caughtor dtchred inyour mrthod. Ifan exception can be handkd meaningfilly in a method, the merhod rhould catch the exceprion rarher than declare ir. Unlike checked exceptions, rhe Java compiler does not check the code to determine whether an unchecked exception is caughr or declared. Unchecked exceptions typically can be prwented by proper coding. For example, the unchecked Ari thmeti cexcepti on thrown by merhod quotient (lines 9-13) in Fig can be avoided if the merhod ensures that the dennminator is not zero before attempting to perfnrm the division. Unchecked exceptions are not rquired to be lisred in a method's throws clause-even if &ey are, it is nnr required that such exceptions be caught by au application. Software Fn~ineering Observation Alrhough the compiltr don not enforre thr catch-or-declare rquirement for unchecked mphonr, provide appropriate exception-handling codz when ii U known thar such mptions might ocnrr. For exampk, uprogram ihouldprorerr tht ~umber~ormat~xceptionfrom Integer merhod parselnt, pvcn though N~uberFormatException (a rubch of RuntimeException) ir un unchecked txreption type. This make~yourprogramr more roburr. Various exception classes can be derived from a common superclass. If a catch handler is writren to carch exception objects of a superclass type, it can also catch al1 objects ofthat class's subclasses. This enahles a catch block to handle related errors with a concise notation and allows for polymorphic processing of related exceptions. One could certainly catch each subclass type individually if those exceptions required different processing. Of course, catching related exceptions in one catch block makes sense only if the handling behavior is the same for al1 subclasses. If there are multiple catch blocks that match a particular exception type, only the first rnatching catch block executes when an exception of that type occurs. We stated earlier that it is a compilation error to catch the same type in two different catch blocks associated with a particular try block. This occurs when both types are exactly the same. However, there may be severa1 catch blocks that match an exception-.e., several catch blocks whose types are the same as the exception type or a superclass of that type. For instance. wecould foílow a catch block for type ArithmeticException with a catch block for type Exception-both would match ArithmeticExceptions, but only the first matching catch block wouid execute. Error-Prevention Tip 13.6 Catchingrubclarr typrr individually U rubject to error ifyouforget ro rertfor one or morr of the subekm typer erplicitly; carching rhe suprrch guarantees thnt objem of al1 subchser will be caught Posirioninga ca tch blockfor the ruperclarr type after al1 other rubchs ca tch blockrfor rubcher of that iupcrclirr ensum rhat al1 rubckzu exreptionr are eventual4 caught. Comrnon Prograrnrning Error 13.7 Placinga catch blockfora suprrch exception type beforr othm catch blocks rhatratch subch~ actption typerprtuenti thoic blorkrfrom rxecuting, io a compilarion error ocnrrs.

15 652 Chapter 13 Exception Handling 1-1 final 1 y block Programs that obtain certain types of resources must return them to the system explicitly to avoid so-called resource leaks. In programming languages such as C and C++, the most common kind of resource leak is a memoty leak. Java performs automatic garbage collection of memory no longer used by programs, rhus avoiding most memory leaks. Howwer, other types of resource leaks can occur. For example, files, database connections and network connections that are not closed properly might not be available for use in other programs. Error-Prevention Tip 13.7 A ruhtle Uiue ii thar Java doei not entirely eliminate memo>y kakr. Java lurll notgarbage collect an object until there are no more refrrencer to ir. Thw mrmoy leakr can ocnrr, $ppropammrrr erronmurly ketp rofertncri to unuanted objccts. The final 1 y block (which consists of the final 1 y keyword, followed by code enclosed in curly braces) is optional, and is sometimes referred to as the final1 y clause. If it is present, iris placed afrer the last catch block, as in Fig. 13.4: Java guarantees that a finally block (if one is present in a try statement) will execute whether or not an exception is thrown in the corresponding try block or any of its corresponding catch hlocks. Java also guarantees that a finally block (if nne is present) will execute fa try blockexits by usinga return, break or continue statement. The finally block will not execute if the application exits early from a try block by calling method System.exit. This merhod, which we demonstrate in the next chapter, immediately terminates an application. Because a final 1 y block almost always executes, it typically contains resource-release code. Suppose a resource is allocated in a t ry block. If no exception occurs, the catch blocks trv 1 sfafemenrs resource-acqui~itiun staternents }..!,<iíl-\ catch ( AKindOfExreprion exceptiunl ) t e.rr.eption-handling sranment.~ },,l-.cl C<,TC>? catch ( AnorhrrKindOfErception exception2 ) 4 exceptron-handling sraremenrs 1 etir i.~tc li finally Fig Position of the finally block after the last catch block in a try statement.

16

17 654 Chapter 13 Exception Handling <.;:..,,..: i:,. ti-,..,r!i < 'l... i i,i;i11\ public static void throwexception() throws Exception System.out.println( "Merhnd rhrowtrception" ); throw new Exceptiono; /; qeneralr rxreution }, 1.. catch ( Exception exception ).! : a8c+,,y:.:i,i! 11, c,,,,?,r- v i System.err.println( ''~>rept i0~1 ha~xile<l i, tmethoil ~ thr~i~!exceorion" ); throw exception; I; - f 1'iirrhi:i- ~ii.o~essiiiri } ~,,ci~~::rl, finally / <>xr,ciit.es ~r~cjart!li!~~ 01' ivhrit i'rcur'i ~II ir"...c<it5li f i... i - : 1, :. : P l i 1) $".!,,..,7 vr,,pyc,,,, 9 i,.,,, <,rc,,,- pub1 i c stati c void doesnotthrowexception~) i System.out.println( ""4etIirid iiopcnortl~r-owcxieli~ ioii" ); },.,,,.. J.. catch ( Exception exception )., rlriai r1c.t e\ic~!fli System.err.println( exception ); }..m r~.: <~!, finally '/ rsx-ruri.s r<,qaidleis rif what cicciiri in rrv...c;llih r Fig try... catch... finally exception-handling rnechanisrn. (Part 2 of 3.)

18

19 656 Chapter 13 Exception Handling Rethrowing Exceptions Line 33 of Fig rcrlirows rlic exccprioii. Exceptions are rethrown when a catch block, upon receiving an exception, decides either rhat ir cannot process that exception or that ir can only partially process it. Rethrowing an exception defers the exception handling (or perhaps a portion of it) to another catch block associated with an outer try statement. An exceprion is rethrown by using the throw keyword, followed by a reference to the exception object that was just caught. Note that exceptions cannot be rethrown frorn a final 1 y hlock, as the exception parameter from the catch hlock has expired. When a rethrow occurs, the next enclosing try block detects the rethrown exception, and that try block's catch blocks attempt to handle the exception. In this case, the next enclosing try block is found at lines 9-12 in method main. Before the rethrown exception is handled, howwer, the final 1 y block (lines 38-41) executes. Then method mai n detects the rethrown exception in the try block and handles ir in the catch block (lines 13-16). Next, main calls rnethod doesnotthrowexception (line 18). No exception is thrown in doesnotthrow~xception's try block (lines 50-53), so the program skips the catch block (lines 54-57), but the finally block (lines 58-62) nwertheless executes. Control proceeds tu the staternent after the final 1 y hlock (line 64). Then control returns tu main and the program terminates. Common Programming Error 13.8 Ifan esctption ha1 not bcen caught when connolenterr a final7y block and the final ly block throwr an csccption that ii not caught in the fina 1 ly block, thejrsr mceprion will be loit and the rxctptionfiom the finallv block will be rctunzed to the calling mtthod. Error-Prevention Tip 13.9 Auoidplacing code thar can throw un exception in a final ly block. lfsuch rodc ir required, enclose the cod~ in a try... catch within the finally bbck. Cornmo? Proeramminr: Error 11.4 Asruming. that an exreption thrownfrom a catch block will bcprocerrrd by that catch block or any other ca tch block asociated uiith the rame try rtatement can [Ead to logic error,. Good Proeramming Practice 13.2 Java I txccption-handlin~ mechaniim ir intendcd ro remove error-procerring cod+m thr main linr of a programi code to improve prognrm clarity. Do not placr try... catch... finally around tmry rtatemcnt that may throw an eccption. Thir rnaker programr drfficrrlt to rcad Rather, place one try blork arounda ripif;canrportion qfyour codc,follnw that try block with catch blocks that handle earhpoiiible exception andfollow the catch blockr with a ring.le fina 1 IY block (yone ir reqquirfd). '?.o Stack Unwinding When an exceprion is rhrown hut oot caught in a particular scope, the method-cal1 stack is "unwound," andan attempt is made tu catch the exception in the next outer try block. This process is called stack iinwincling. Unwinding rhe method-cal1 stack rneans that the rnethod in which rhe exception was not caught terminares, al1 local variables in that method go out of scope and control returns to the staternent that originally invoked that meth-

20 13.8 Stack Unwinding 657 od. Ifa try block encloses that statement, an atternpt is made to catch the exception. If a try block does not enclose that statement, stack unwinding occurs again. If no catch block ever catches this exception and the exception is checked (as in the following exam- I $e), compiling the program will result in an error. The program of Fig dernonstrates 1 stack unwinding. I When method mai n executes, line 10 in the try block calls rnethod throwexception! (lines 19-35). In the try block of method throwexception (lines 21-25), line 24 throws an Exception. This terminates the try block immediately, and control skips the catch block at line 26, because the type being caught (RuntimeException) is notan exact match i 1, Fic,. 1;.1>: 1;5,,1c,1 x<v,~,tl"n5.~j3"~3 2,, o n : ii.ir1, iiiiii I iiiiiiiri public class UsingExceptions 1 I 6 public static void main( String args[l ) 1 8 try r:~!l : ~ r ~ m ~,!:c., ~ ~I~~~~,~C~I~,~! F ~ ~ I,?:e ~ ~ :1,3c!< ~ ~ ~II:',. ~ m:~<li!*<i < ~ r ~ 1 9 { 1 O throwexceptiono ;,,,., \ tch ( Exception exception ) // excebpiii,ii iiii-i.i,.ri in rh!.o\,4\it,!ir'-r., 18. I,, l t t t o n! 15 i r i i cat~,il>+ 18, :l.:,:!,'-:!>n:\ 19 public static void throwexception0 throws Exception 20 { 2 1 try 12 I ' t11:-rw ir, c~~ro~rri:in :in<! i.itrli ir i!,.i:iiii 23 System.out.println( "Method throwexceptinn" ); 24 throw new ExceptionO;,'; ~rnriztr ~kceprior 25 } VI,,! tm 26 catch ( RuntimeException runtimeexception ), i,iirli ~8t?c~:-rswc~ t\$w 27 { 28 System.err.println( 29 'Lxcept ioii handled in metliod throwexreptiun" 1; 10 }..,.!i..!<.l. 31 finally ' ii ri?lli lhlnil< a!,,'.ibs ~1~rilrP5 12 { 33 System.err.println( "Finally is alivayc exer~itprl" ); 14 }, c3#,t, k 183'1 1 1 " 35 } +n<! 8m~tl~~~rI 1 Ihv~~w~Fx~ el>t7nn 36 } : ~ 1 i i 1 I!:,v. Ic~iicir~in~irioris Method throwexception Finally is always executed Exception handled in main L.... Fig Stack unwinding

21 658 Chapter 13 Exception Handling with rhe thrown type (Exception) and is nota superclass of ir. Merhod throwexception terminates (hut not until its final1 y block executes) and returns control to line 10-the point from which ir was called in the program. Line 10 is in an enclosing try block. Tbe exception has not yet heen handled, so the try block terminates andan attempt is made to catch the exception at line 12. The rype being caught (Exception) does match the thrown type. Consequently, the catch block processes the exception, and the program terminates at the end of mai n. If there were no matching catch blocks, a compilation error would occur. Remember that this is not always the case-for unchecked exceptions, the application will compile, but run with unexpected results. 9.0 printstacktrace, getstacktrace and getmessage Recall from Section 13.6 that exceptions derive from class Throwabl e. Class Throwabl e offers a printstackirace method that outputs to the standard error stream the stack trace (discussed in Section 13.3). Often, this is helpful in testing and debugging. Class Throwable also provides a getstacktrace method that retrieves stack-trace information that might be printed by printstacktrace. Class Throwable's getmessage method returns the descriptive string stored in an exception. The example in this section demonstrates these rhree methods. Q Error-?rev~ntion Tip An exctption thnt ir not caught in an application causes Java'r default exception handkr to nrn. Thir displayr the name of the rxception, a dpsmiptiur message that indicater theproblem that ocmrred and a complete execution itack nact. Frror-Drevention Tip Throwab le mrthod tostring (inherited by al[ Throwable subcíarses) returnr a rtringrontaining tht name of rhe mctprion I r h and a dercriptiue messagc. Figure 13.7 demonstrates getmessage, pri ntstacktrace and getstacktrace. If we wanted to output the stack-trace information to streams other than the standard error stream. we could use the information returned from getstacktrace, and output this data to another stream. You will learn about sending data to other streams in Chapter 14, Files and Streams. In main, the try block (lines 8-11) calls methodl (declared at lines 35-38). Next, methodl calls method2 (declared at lines 41-44), which in turn calls method3 (declared at lines 47-50). Line 49 of method3 throws an Exception ohject-this is the throw point. Because throw statement at line 49 is nor enclosed in a try block, stack unwinding occur~ethod3 terminates at line 49, then returns control to the statement in method2 that invoked method3 (.e., line 43). Because no try block encloses line 43, stack unwinding occurs again-method2 terminates at line 43 and returns control to the statement in methodl that invoked method2 (.e., line 37). Because no try block encloses line 37, stack unwinding occurs one more time-methodl terminates at line 37 and returns control to the staremenr in mai n that invoked methodl (.e., line 10). The try block at lines encloses this statement. The exception has not heen handled, so the try block terminates and the first matching catch block (lines 12-31) catches and processes the exception.

22 13.9 printstacl<trace. getstacktrace and getmessage 659 I 2,,.,..(,.., 1 4 publi c class Usi ngexceptions 5 I 6 public static void main( String args[l ) 7 I 8 try 9 I 1 o methodl() ; /,~.; :.,$ A!:...! i catch ( Exception exception ) 1,,.. : ' S,,; Il I 14 System.err.printf( "'i;n' n", exception.getmessage0 1;,, 15 exception.printstacktrace();..,,.....,, , I I,. 18 StackTraceElem ception.getstacktrace0; System.out.println( '"~~í!.!t:l.. tr~.?<:,, frur g!~?:taclt7,,.c*:" 1; 21 System.out.println( ''<las5,r TIY! wt,! ' T I i;-.*-, t\kh.>~!' 1; <,.. 1,. :,, / : i ~ 24 for ( StackTrac 25 { 26 System.out.printf( "' r element.getclassname0 1; 27 System.out.printf( ' i\r", element.getfilename0 ); 18 System.out.printf( ".S\ r", element.getlinenumber0 ); 29 System.out.printf( " 5'ri". element.getmethodname0 1; 30 } ;., ,, 12 1.,, ,I,.,$. l,,,:?.,, 15 public static voi ception method 38 } 39 / 40.,.,,. : l. :, I. r;.,. 41 public stati c void method20 throws Exception 42 I 43 method30 ; : >,,, 44 1 i l., l :,,,,.,,,,-[, :~,,,,! 1,,,,,,, r,,.::,,~,,!,' 47 public static void method30 throws Exception 48 I 49 throw new Exception( "Excepíion thiown in mrthod3" 1; 50 I...,..., < ;,! 1,.>., < Fig of 2.) Throwable rnethods getmessage. getstacktrace and printstacktrace. (Part I

23 660 Chapter 13 Exception Handling Exception thrown in method3 iava.lana.exceotion: Exceotion thrown in method3 Stack trace from getstacktrace: Class File Line Method UsinuExceotions UsinqExceotions.iava 37 methodl ~sin~~xceptions ~sin~~xceptions.java 10 mai n Fig Throwable methods getmessage. getstacktrace and printstacktrace (Part 2 of2) Line 14 invokes the exception's getmessage method to get the exception description. Line 15 invokes the exception's printstacktrace method to output the stack trace that indicates where the exception occurred. Line 18 invokes the exception's getstacktrace method to obtain the stack-trace information as an array of StackTraceElement objects. Lines get each StackTraceElement in the array and invoke its methods getclass- Name, getfilename, getlinenumber and getmethodname to get the cíass name, fiie name, line number and merhod name, respectively, for rhat StackTraceElement. Each Stack- TraceElement represents one method cal1 on the method-cal1 stack. The output in Fig shows that the stack-trace information printed by print- StackTrace follows the pattern: clasrname.methodname(filename:linenumber), where clasname, methodnamc andfilename indicate the names of the class, method and file in which the exceprion occurred, respectively, and the linenumber indicates where in rhe file the exception occurred. You saw this in the output for Fig Method getstacktrace enables custom processing of the exception information. Compare the output of print- StackTrace with the output created from [he StackTraceElements to see that both contain the same stack-trace information. -Software Eneineerine Obsewation m ~ r r eicyan r exceptionyou catch. At leair urt print5tacktrace to ourpur an error mesiagp. Thir wrii rnfonn urerr that a probhm exirtr, so that th~y can take appropriate artionr '?.! 9 Chained Exceptions Sometimes a catch block catches one exception type, then throws a new exception of a differenr type to indicate thar a program-specific exception occurred. In earlier Java versions, there was no mechanism to wrap the original exception information with the new exception's inforrnation to provide a complete stack trace showing where the original problem occurred in the program. This made debugging such problems particularly difficult. JZSE 1.4 added chaincd exceptions to enable an exception object to maintain the complete stack-trace information. Figure 13.8 presents a mechanical example that demonstrares how chained exceptions work.

24 13.10 Chained Exceotions public class Usi ngchainedexceptions 5 I 6 public static void main( String args[l ) 7 I i! i ~~i.';i.il.':!i-,i-n,v Piii.,?!,i,,< ii,?,% ir,.!i;in public static void methodlo throws Exception I trv 22 I 23 method20; ;' c i~,l ~!~~~~170~!2 24 } 25 catch ( Exception exception ) 1; ~yrr.;i*ir,,: rhroi\;~ Frmn ~xc-rl~n~i' throw new Exception( "Exceotion thrown in methodl", exception ); 28 }.,,. I 20 },3>~,#,:1, > m :;.,<!,,,r: <> , 8...o, 1::i :: rl.ly,\., pv:;ip+:",i' /JC!<* ~ i : rirhciil 32 public static void method20 throws Exception 31 I 34 trv 3 S i 36 method30; ':!: 7,-~i+:w!?, 37 }. ; 30 catch ( Exception exception ) ;! e~i~iitirin throiyn from ~npll~orii 3q { 40 throw new Exceptionc "Exception thrown in nl~thodz", exception ); 41., ', 42 1 r.!,:! l:r>,l #vmt~i>,?,l? Vil i;i.! 1 O!! Ii,i.~L L<, l~lt~~~i,<,~l,~' 45 public static void method30 throws Exception. 46 { 47 throw new Exceptionc "Fxception thrown in method3" ); 48 }.,;.. i ii.... -'i,,,: 49 } el?!! < 1,:.5 iii~iril.i,i iiitatlfki<?nt irin5 Fig Chained exceptions. (Part I of 2.)

25 662 Chapter 13 Exception Handling java.lang.exception: Exception thrown in methodl at UsingChainedExceptions.methodl(UsingChainedExceptions. java: 27) at UsingChainedExceptions.mai n(usingchainedexcepti0ns. java: 10) Caused by: java.lang.exception: Exception thrown in method2 at UsingChainedExceptions.method2(UsingChainedExceptions. java:40) at UsingChainedExceptions.methodl(UsingChainedExceptions.java:23)... 1 more Caused by: java.lang.exception: Exception thrown in method3 at UsingChainedExceptions.method3(UsingChainedExceptions. java:47) at UsingChainedExceptions.method2(UsingChainedExceptions. java: 36)... 2 more - - Fig Chained exceptions (Pari 2 of 2 ) The program consists of four merhods-main (lines G16), methodl (lines 19-29). method2 (lines 32-42) and method3 (lines 4548). Line 10 in method main's try block calls methodl. Line 23 in methodl's try block calls method2. Line 36 in method2's try block calls method3. In method3, line 47 throws a new Exception. Because this statement is not in a try block, method3 terminates, and the exceprion is returned to the calling method (method2) at line 36. This statement ir in a try block; therefore, the try block terminates and the exception is caught at lines Line 40 in the catch block throws a new exceprion. In this case, the Excepti on constructor with two arguments is called. The second argument represents the exception that was the original cause of the problem. In this program, that exception occurred at line 47. Because an exception is thrown from the catch block, method2 terminates and returns the new exception to the calling method (methodl) at line 23. Once again, this statement is in a try block, so the try block terminates and the exception is caughr at lines Line 27 in rhe catch block rhrows a new exception and uses the exception rhat was caught as the second argument to the Excepti on constructor. Because an exception is thrown from the catch block, methodl terminares and returns the new exception to the calling method (main) at line 10. The try block in main terminates, and the exception is caught at lines Line 14 prints a stack trace. Notice in the program output that the first three lines show the most recent exception that was thrown (.e., the one from methodl at line 23). The nexr four lines indicate the exception that was thrown from method2 at line 40. Finally, the last four lines represent the exception that was thrown from method3 at line 47. Also notice that, as you read the output in reverse, ir shows how many more chained exceptions remain.! 3. i I Declaring New Exception Types Most Java programmers use existing classes from the Java API, third-parry vendors and freely available class libraries (usually downloadable from the Internet) to build Java applications. The methods of those classes typically are declared to throw appropriate exceptions when problems occur. Programmers write code that processes these existing exceprions to make programs more robust. If you are a programmer who builds classes that other programmers will use in their programs, you might find ir usehil to declare your own exception classes that are specific to the problems that can occur when another programmer uses your reusable classes.