Kĩ thuật lập trình - Exception handling

13Exception Handling1 It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.Franklin Delano RooseveltO! throw away the worser part of it, And live the purer with the other half.William ShakespeareIf they’re running and they don’t look where they’re going I have to come out from somewhere and catch them.Jerome David SalingerO infinite virtue! com’st thou smiling from the world’s great snare uncaught?William Shakespeare2OBJECTIVESIn this chapter you will learn:How exception and error handling works.To use try, throw and catch to detect, indicate and handle exceptions, respectively.To use the finally block to release resources.How stack unwinding enables exceptions not caught in one scope to be caught in another scope.How stack traces help in debugging.How exceptions are arranged in an exception class hierarchy.To declare new exception classes.To create chained exceptions that maintain complete stack trace information.3 13.1   Introduction 13.2   Exception-Handling Overview 13.3   Example: Divide By Zero Without Exception Handling 13.4   Example: Handling ArithmeticExceptions and InputMismatchExceptions 13.5   When to Use Exception Handling 13.6   Java Exception Hierarchy 13.7   finally block 13.8   Stack Unwinding 13.9 printStackTrace, getStackTrace and getMessage13.10   Chained Exceptions13.11   Declaring New Exception Types13.12   Preconditions and Postconditions13.13   Assertions13.14   Wrap-Up413.1 IntroductionException – an indication of a problem that occurs during a program’s executionException handling – resolving exceptions that may occur so program can continue or terminate gracefullyException handling enables programmers to create programs that are more robust and fault-tolerant5Error-Prevention Tip 13.1Exception handling helps improve a program’s fault tolerance. 613.1 IntroductionExamplesArrayIndexOutOfBoundsException – an attempt is made to access an element past the end of an arrayClassCastException – an attempt is made to cast an object that does not have an is-a relationship with the type specified in the cast operatorNullPointerException – when a null reference is used where an object is expected713.2 Exception-Handling OverviewIntermixing program logic with error-handling logic can make programs difficult to read, modify, maintain and debugException handling enables programmers to remove error-handling code from the “main line” of the program’s executionImproves clarityEnhances modifiability8Performance Tip 13.1If the potential problems occur infrequently, intermixing program and error-handling logic can degrade a program’s performance, because the program must perform (potentially frequent) tests to determine whether the task executed correctly and the next task can be performed. 913.3 Example: Divide By Zero Without Exception HandlingThrown exception – an exception that has occurredStack traceName of the exception in a descriptive message that indicates the problemComplete method-call stackArithmeticException – can arise from a number of different problems in arithmeticThrow point – initial point at which the exception occurs, top row of call chainInputMismatchException – occurs when Scanner method nextInt receives a string that does not represent a valid integer10Attempt to divide; denominator may be zeroRead input; exception occurs if input is not a valid integer111213.4 Example: Handling ArithmeticExceptions and InputMismatchExceptionsWith exception handling, the program catches and handles (i.e., deals with) the exceptionNext example allows user to try again if invalid input is entered (zero for denominator, or non-integer input)13Enclosing Code in a try Blocktry block – encloses code that might throw an exception and the code that should not execute if an exception occursConsists of keyword try followed by a block of code enclosed in curly braces14Exceptions may surface through explicitly mentioned code in a try block, through calls to other methods, through deeply nested method calls initiated by code in a try block or from the Java Virtual Machine as it executes Java bytecodes.Software Engineering Observation 13.115Catching Exceptionscatch block – catches (i.e., receives) and handles an exception, contains:Begins with keyword catchException parameter in parentheses – exception parameter identifies the exception type and enables catch block to interact with caught exception objectBlock of code in curly braces that executes when exception of proper type occursMatching catch block – the type of the exception parameter matches the thrown exception type exactly or is a superclass of itUncaught exception – an exception that occurs for which there are no matching catch blocksCause program to terminate if program has only one thread; Otherwise only current thread is terminated and there may be adverse effects to the rest of the program16Common Programming Error 13.1It is a syntax error to place code between a try block and its corresponding catch blocks. 17Common Programming Error 13.2Each catch block can have only a single parameter—specifying a comma-separated list of exception parameters is a syntax error. 18Termination Model of Exception HandlingWhen an exception occurs:try block terminates immediatelyProgram control transfers to first matching catch blockAfter exception is handled:Termination model of exception handling – program control does not return to the throw point because the try block has expired; Flow of control proceeds to the first statement after the last catch blockResumption model of exception handling – program control resumes just after throw pointtry statement – consists of try block and corresponding catch and/or finally blocks19Common Programming Error 13.3Logic errors can occur if you assume that after an exception is handled, control will return to the first statement after the throw point. 20Error-Prevention Tip 13.2With exception handling, a program can continue executing (rather than terminating) after dealing with a problem. This helps ensure the kind of robust applications that contribute to what is called mission-critical computing or business-critical computing. 21Good Programming Practice 13.1Using an exception parameter name that reflects the parameter’s type promotes clarity by reminding the programmer of the type of exception being handled. 22Using the throws Clausethrows clause – specifies the exceptions a method may throwsAppears after method’s parameter list and before the method’s bodyContains a comma-separated list of exceptionsExceptions can be thrown by statements in method’s body of by methods called in method’s bodyExceptions can be of types listed in throws clause or subclasses23Error-Prevention Tip 13.3If you know that a method might throw an exception, include appropriate exception-handling code in your program to make it more robust. 24Error-Prevention Tip 13.4Read the online API documentation for a method before using that method in a program. The documentation specifies the exceptions thrown by the method (if any) and indicates reasons why such exceptions may occur. Then provide for handling those exceptions in your program. 25Error-Prevention Tip 13.5Read the online API documentation for an exception class before writing exception-handling code for that type of exception. The documentation for an exception class typically contains potential reasons that such exceptions occur during program execution. 26throws clause specifies that method quotient may throw an ArithmeticExceptionRepetition statement loops until try block completes successfullytry block attempts to read input and perform divisionRetrieve input; InputMismatchException thrown if input not valid integers27Call method quotient, which may throw ArithmeticExceptionIf we have reached this point, input was valid and denominator was non-zero, so looping can stopCatching InputMismatchException (user has entered non-integer input)Read invalid input but do nothing with itException parametersNotify user of error madeCatching ArithmeticException (user has entered zero for denominator)If line 32 was never successfully reached, loop continues and user can try again282913.5 When to Use Exception HandlingException handling designed to process synchronous errorsSynchronous errors – occur when a statement executesAsynchronous errors – occur in parallel with and independent of the program’s flow of control30Software Engineering Observation 13.2Incorporate your exception-handling strategy into your system from the design process’s inception. Including effective exception handling after a system has been implemented can be difficult. 31Software Engineering Observation 13.3Exception handling provides a single, uniform technique for processing problems. This helps programmers working on large projects understand each other’s error-processing code. 32Avoid using exception handling as an alternate form of flow of control. These “additional” exceptions can “get in the way” of genuine error-type exceptions. Software Engineering Observation 13.433Software Engineering Observation 13.5Exception handling simplifies combining software components and enables them to work together effectively by enabling predefined components to communicate problems to application-specific components, which can then process the problems in an application-specific manner. 3413.6 Java Exception HierarchyAll exceptions inherit either directly or indirectly from class ExceptionException classes form an inheritance hierarchy that can be extendedClass Throwable, superclass of ExceptionOnly Throwable objects can be used with the exception-handling mechanismHas two subclasses: Exception and ErrorClass Exception and its subclasses represent exception situations that can occur in a Java program and that can be caught by the applicationClass Error and its subclasses represent abnormal situations that could happen in the JVM – it is usually not possible for a program to recover from Errors35Fig. 13.3 | Portion of class Throwable’s inheritance hierarchy. 3613.6 Java Exception HierarchyTwo categories of exceptions: checked and uncheckedChecked exceptionsExceptions that inherit from class Exception but not from RuntimeExceptionCompiler enforces a catch-or-declare requirementCompiler checks each method call and method declaration 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. If not caught or declared, compiler error occurs.Unchecked exceptionsInherit from class RuntimeException or class ErrorCompiler does not check code to see if exception is caught or declaredIf an unchecked exception occurs and is not caught, the program terminates or runs with unexpected resultsCan typically be prevented by proper coding37Software Engineering Observation 13.6Programmers are forced to deal with checked exceptions. This results in more robust code than would be created if programmers were able to simply ignore the exceptions. 38Common Programming Error 13.4A compilation error occurs if a method explicitly attempts to throw a checked exception (or calls another method that throws a checked exception) and that exception is not listed in that method’s throws clause. 39Common Programming Error 13.5If a subclass method overrides a superclass method, it is an error for the subclass method to list more exceptions in its throws clause than the overridden superclass method does. However, a subclass’s throws clause can contain a subset of a superclass’s throws list. 40Software Engineering Observation 13.7If your method calls other methods that explicitly throw checked exceptions, those exceptions must be caught or declared in your method. If an exception can be handled meaningfully in a method, the method should catch the exception rather than declare it. 41Software Engineering Observation 13.8Although the compiler does not enforce the catch-or-declare requirement for unchecked exceptions, provide appropriate exception-handling code when it is known that such exceptions might occur. For example, a program should process the NumberFormatException from Integer method parseInt, even though NumberFormatException (a subclass of RuntimeException) is an unchecked exception type. This makes your programs more robust. 4213.6 Java Exception Hierarchycatch block catches all exceptions of its type and subclasses of its typeIf there are multiple catch blocks that match a particular exception type, only the first matching catch block executesIt makes sense to use a catch block of a superclass when all the catch blocks for that class’s subclasses will perform the same functionality43Error-Prevention Tip 13.6Catching subclass types individually is subject to error if you forget to test for one or more of the subclass types explicitly; catching the superclass guarantees that objects of all subclasses will be caught. Positioning a catch block for the superclass type after all other subclass catch blocks for subclasses of that superclass ensures that all subclass exceptions are eventually caught. 44Common Programming Error 13.6Placing a catch block for a superclass exception type before other catch blocks that catch subclass exception types prevents those blocks from executing, so a compilation error occurs. 4513.7 finally blockPrograms that obtain certain resources must return them explicitly to avoid resource leaksfinally blockConsists of finally keyword followed by a block of code enclosed in curly bracesOptional in a try statementIf present, is placed after the last catch blockExecutes whether or not an exception is thrown in the corresponding try block or any of its corresponding catch blocksWill not execute if the application exits early from a try block via method System.exitTypically contains resource-release code46Error-Prevention Tip 13.7A subtle issue is that Java does not entirely eliminate memory leaks. Java will not garbage collect an object until there are no more references to it. Thus, memory leaks can occur, if programmers erroneously keep references to unwanted objects. 47Outline4813.7 finally blockIf no exception occurs, catch blocks are skipped and control proceeds to finally block.After the finally block executes control proceeds to first statement after the finally block.If exception occurs in the try block, program skips rest of the try block. First matching the catch block executes and control proceeds to the finally block. If exception occurs and there are no matching catch blocks, control proceeds to the finally block. After the finally block executes, the program passes the exception to the next outer the try block.If catch block throws an exception, the finally block still executes.49Always release each resource explicitly and at the earliest possible moment at which it is no longer needed. This makes resources immediately available to be reused by your program or by other programs, thus improving resource utilization. Performance Tip 13.250Error-Prevention Tip 13.8Because the finally block is guaranteed to execute whether or not an exception occurs in the corresponding try block, this block is an ideal place to release resources acquired in a try block. This is also an effective way to eliminate resource leaks. For example, the finally block should close any files opened in the try block. 5113.7 finally blockStandard streamsSystem.out – standard output streamSystem.err – standard error streamSystem.err can be used to separate error output from regular outputSystem.err.println and System.out.println display data to the command prompt by default 52Call method that throws an exception53Create new Exception and throw itThrow previously created Exceptionfinally block executes even though exception is rethrown in catch block54finally block executes even though no exception is thrown55Throwing Exceptions Using the throw Statementthrow statement – used to throw exceptionsProgrammers can thrown exceptions themselves from a method if something has gone wrongthrow statement consists of keyword throw followed by the exception object56Software Engineering Observation 13.9When toString is invoked on any Throwable object, its resulting string includes the descriptive string that was supplied to the constructor, or simply the class name if no string was supplied. 57An object can be thrown without containing information about the problem that occurred. In this case, simple knowledge that an exception of a particular type occurred may provide sufficient information for the handler to process the problem correctly.Software Engineering Observation 13.1058Software Engineering Observation 13.11Exceptions can be thrown from constructors. When an error is detected in a constructor, an exception should be thrown rather than creating an improperly formed object. 59Rethrowing ExceptionsExceptions are rethrown when a catch block decides either that it cannot process the exception or that it can only partially process itException is deferred to outer try statementException is rethrown by using keyword throw followed by a reference to the exception object60Common Programming Error 13.7If an exception has not been caught when control enters a finally block and the finally block throws an exception that is not caught in the finally block, the first exception will be lost and the exception from the finally block will be returned to the calling method. 61Error-Prevention Tip 13.9Avoid placing code that can throw an exception in a finally block. If such code is required, enclose the code in a try statement within the finally block. 62Common Programming Error 13.8Assuming that an exception thrown from a catch block will be processed by that catch block or any other catch block associated with the same try statement can lead to logic errors. 63Good Programming Practice 13.2Java’s exception-handling mechanism is intended to remove error-processing code from the main line of a program’s code to improve program clarity. Do not place try... catch finally... around every statement that may throw an exception. This makes programs difficult to read. Rather, place one try block around a significant portion of your code, follow that try block with catch blocks that handle each possible exception and follow the catch blocks with a single finally block (if one is required). 6413.8 Stack UnwindingStack unwinding – When an exception is thrown but not caught in a particular scope, the method-call stack is “unwound,” and an attempt is made to catch the exception in the next outer try block.When unwinding occurs:The method in which the exception was not caught terminatesAll local variables in that method go out of scopeControl returns to the statement that originally invoked the method – if a try block encloses the method call, an attempt is made to catch the exception.65Call method that throws an exceptionCatch exception that may occur in the above try block, including the call to method throwException66Method throws exceptionThrow new exception; Exception not caught in current try block, so handled in outer try blockfinally block executes before control returns to outer try block6713.9 printStackTrace, getStackTrace and getMessageMethods in class Throwable retrieve more information about an exceptionprintStackTrace – outputs stack trace to standard error streamgetStackTrace – retrieves stack trace information as an array of StackTraceElement objects; enables custom processing of the exception informationgetMessage – returns the descriptive string stored in an exception68Error-Prevention Tip 13.10An exception that is not caught in an application causes Java’s default exception handler to run. This displays the name of the exception, a descriptive message that indicates the problem that occurred and a complete execution stack trace. In an application with a single thread of execution, the application terminates. In an application with multiple threads, the thread that caused the exception terminates.69Error-Prevention Tip 13.11Throwable method toString (inherited by all Throwable subclasses) returns a string containing the name of the exception’s class and a descriptive message. 7013.9 printStackTrace, getStackTrace and getMessageStackTraceElement methodsgetClassNamegetFileNamegetLineNumbergetMethodNameStack trace information follows pattern – className.methodName(fileName:lineNumber)71Call to method1, method1 calls method2, method2 calls method3 and method3 throws a new ExceptionDisplay descriptive string of exception thrown in method3Display stack trace for exception thrown in method3Retrieve stack information as an array of StackTraceElement objects72Retrieve class name for current StackTraceElementRetrieve file name for current StackTraceElementRetrieve line number for current StackTraceElementRetrieve method name for current StackTraceElementmethod1 calls method2, method2 calls method3 and method3 throws an Exception73method2 calls method3, which throws an ExceptionException created and thrown74Software Engineering Observation 13.12Never ignore an exception you catch. At least use printStackTrace to output an error message. This will inform users that a problem exists, so that they can take appropriate actions. 7513.10 Chained ExceptionsChained exceptions enable an exception object to maintain the complete stack-trace information when an exception is thrown from a catch blockUsers can retrieve information about original exceptionStack trace from a chained exception displays how many chained exceptions remain76Catch exception from method1 as well as any associated chained exceptions77Catch exception from method2, throw new exception to be chained with earlier exceptionsCatch exception from method3, throw new exception to be chained with earlier exceptions78Original thrown exception7913.11 Declaring New Exception TypesYou can declare your own exception classes that are specific to the problems that can occur when another program uses your reusable classesNew exception class must extend an existing exception classTypically contains only two constructorsOne takes no arguments, passes a default exception messages to the superclass constructorOne that receives a customized exception message as a string and passes it to the superclass constructor80Software Engineering Observation 13.13If possible, indicate exceptions from your methods by using existing exception classes, rather than creating new exception classes. The Java API contains many exception classes that might be suitable for the type of problem your method needs to indicate. 81Good Programming Practice 13.3Associating each type of serious execution-time malfunction with an appropriately named Exception class improves program clarity. 82Software Engineering Observation 13.14When defining your own exception type, study the existing exception classes in the Java API and try to extend a related exception class. For example, if you are creating a new class to represent when a method attempts a division by zero, you might extend class ArithmeticException because division by zero occurs during arithmetic. If the existing classes are not appropriate superclasses for your new exception class, decide whether your new class should be a checked or an unchecked exception class. (cont)83Software Engineering Observation 13.14The new exception class should be a checked exception (i.e., extend Exception but not RuntimeException) if possible clients should be required to handle the exception. The client application should be able to reasonably recover from such an exception. The new exception class should extend RuntimeException if the client code should be able to ignore the exception (i.e., the exception is an unchecked exception). 84Good Programming Practice 13.4By convention, all exception-class names should end with the word Exception. 8513.12 Preconditions and PostconditionsPreconditions and postconditions are the states before and after a method’s executionUsed to facilitate debugging and improve designYou should state the preconditions and postconditions in a comment before the method declaration8613.12 Preconditions and PostconditionsPreconditionsCondition that must be true when the method is invokedDescribe method parameters and any other expectations the method has about the current state of a programIf preconditions not met, method’s behavior is undefinedPostconditionsCondition that is true after the method successfully returnsDescribe the return value and any other side-effects the method may haveWhen calling a method, you may assume that a method fulfills all of its postconditions8713.13 AssertionsAssertions are conditions that should be true at a particular point in a methodHelp ensure a program’s validity by catching potential bugsPreconditions and Postconditions are two kinds of assertionsAssertions can be stated as comments or assertions can be validated programmatically using the assert statement8813.13 Assertionsassert statementEvaluates a boolean expression and determines whether it is true or falseTwo formsassert expression; -- AssertionError is thrown if expression is falseassert expression1 : expression2; -- AssertionError is thrown if expression1 is false, expression2 is error messageUsed to verify intermediate states to ensure code is working correctlyUsed to implement preconditions and postconditions programmaticallyBy default, assertions are disabledAssertions can be enabled with the –ea command-line option89assert statementIf number is less than 0 or greater than 10, AssertionError occursMessage to be displayed with AssertionError90