BOOK NOTES CHAPTER 15 EXCEPTION HANDLING - point of error detection and point of error recovery often decoupled - exception handling - flexible mechanism - pass control from point of detection to competent recovery handler 15.1 THROWING EXCEPTIONS - what a method should do when it detects an error condition - traditional solution - return a value that indicates whether it succeeded or failed - problematic - caller forgets to check return value: failure undetected - caller can't do anything about the failure - must also fail - must propagate to own caller - many method calls would need to be checked for failure - programs get hard to read - exception handling mechanism - exceptions can't be overlooked - exceptions are sent directly to an exception handler, not necessarily the caller of the failed method - detect error - throw an appropriate exception object - use throw statement - look for appropriate exception class - many provided by Java library - should describe error situation - current method terminates immediately - execution continues with an exception handler - syntax: throwing an exception throw 15.2 CHECKED AND UNCHECKED EXCEPTIONS - checked exception - call method that throws checked exception - compiler checks that you don't ignore it - must tell compiler what you are going to do about the exception if it is thrown - all subclasses of Exception that are not descendants of RuntimeException - likely to occur at times, no matter how careful you are - compiler insists that you handle because you cannot prevent with good programming - majority deal with IO - what to tell compiler - handle exception - aware of exception and want method to be terminated when it occurs - tag the method with a throws specifier syntax: exception specification throws - signals the caller that it may encounter that exception - throws multiple different exceptions - use comma delimited list in throws clause - remember that different means have no common ancestor in the inheritance hierarchy - best not to handle unless you know how to fix the situation - let methods that do know how to communicate with the user or take other remedial action handle - make possible for exception to be processed by competent handler - unchecked exceptions - compiler does not require you to keep track of - descendants of RuntimeException - descendants of Error - fatal errors - happen rarely - beyond your control - your fault - compiler does not require you to handle because if you program correctly, you won't encounter them 15.3 CATCHING EXCEPTIONS - every exception that your program might throw should be handled somewhere in your program - unhandled exception is thrown - error message printed - program terminates - try/catch statement - try block contains one or more statements that may cause an exception - catch clause contains the handler for an exception type - syntax: general try block try { } catch ( ) { } ... - exception object contains reference to object that was thrown - catch clause can analyze to find more details about failure - Exception::printStackTrace() prints the chain of method calls that led to the exception - if exception is thrown - rest of instructions in try block are skipped - first catch block that matches exception type (or ancestor of exception type) is executed - if the type matches none of the catch blocks, it is not caught - contents of catch clause - inform the user of the source of problems - better: give the user another chance to provide correct input QT 15.1 THROW EARLY, CATCH LATE - better to throw an exception than to come up with an imperfect fix - method should only catch an exception if it can really remedy the situation, otherwise, should propagate QT 15.2 DO NOT SQUELCH EXCEPTIONS - compiler complains if don't specify a handler for a checked exception - don't write a do-nothing try-catch block - exceptions were designed to report problems to a competent handler - hides an error condition that could be serious 15.4 THE FINALLY CLAUSE - take some action whether or not an exception is thrown - finally clause after try block - syntax: finally clause try { } finally { } - normal case: executed after the try block successfully completes - exception is thrown: executed before the exception is passed to its handler - use whenever need to ensure cleanup occurs regardless of how method exits - finally clause after catch block executes - after completing the last statement of the try block - after completing the last statement of a catch clause, if this try block caught an exception - when an exception is thrown in the try block and not caught - recommend don't mix catch and finally clauses in same try block QT 15.3 DO NOT USE CATCH AND FINALLY IN THE SAME TRY STATEMENT - hard to understand resulting code - use try/finally statement to close resources - use separate try/catch statement to handle errors - nest try/finally statement in try block of corresponding try/catch statement 15.5 DESIGNING YOUR OWN EXCEPTION TYPES - none of the standard exception types describe your particular error condition well enough - design your own exception class - decide whether it is checked or unchecked - checked - fault of some external event - extend Exception class - unchecked - fault of the programmer - extend RuntimeException class - provide two constructors - default constructor - constructor that accepts a message string - parameter describes the reason for the exception - can be retrieved via the getMessage method - should include a call to super(); QT 15.4 DO THROW SPECIFIC EXCEPTIONS - choose an exception class that describes the situation as closely as possible - avoid catch blocks catching exceptions caused by other events (especially caused when have common ancestor) - if standard library does not have an exception class that describes the situation, define a new exception class 15.6 CASE STUDY: A COMPLETE EXAMPLE - identify what can go wrong - decide who can detect the faults - decide which exceptions can be thrown: means using a class that automatically throws exceptions - decide whether need to throw own exceptions - decide which method can remedy the faults that the exceptions report - separation between error detection and error handling