ExceptionsErrors and ExceptionsWhat to do about errors and exceptionsDealing with exceptionsThe problem with exceptionsThree approaches to error checkingThe try statementException handling is not optionalError and Exception are ObjectsThe exception hierarchyThe Exception hierarchy IIKinds of ExceptionsWhat to do about ExceptionsWhat to do about Exceptions IIHow to use the try statementHow the try statement worksOrdering the catch phrasesUsing the exceptionprintStackTrace()Throwing an ExceptionConstructing an ExceptionSlide 22Why create an Exception?The EndExceptionsErrors and Exceptions•An error is a bug in your program–dividing by zero–going outside the bounds of an array–trying to use a null reference•An exception is a problem whose cause is outside your program–trying to open a file that isn’t there–running out of memoryWhat to do about errors and exceptions•An error is a bug in your program–It should be fixed•An exception is a problem that your program may encounter–The source of the problem is outside your program–An exception is not the “normal” case, but...–...your program must be prepared to deal with it•This is not a formal distinction–it isn’t always clear whether something should be an error or an exceptionDealing with exceptions•Most exceptions arise when you are handling files–A needed file may be missing–You may not have permission to write a file–A file may be the wrong type•Exceptions may also arise when you use someone else’s classes (or they use yours)–You might use a class incorrectly–Incorrect use should result in an exceptionThe problem with exceptions•Here’s what you might like to do:–open a file–read a line from the file•But here’s what you might have to do:–open a file–if the file doesn’t exist, inform the user–if you don’t have permission to use the file, inform the user–if the file isn’t a text file, inform the user–read a line from the file–if you couldn’t read a line, inform the user–etc., etc.•All this error checking really gets in the way of understanding the codeThree approaches to error checking1. Ignore all but the most important errors–The code is cleaner, but the program will misbehave when it encounters an unusual error2. Do something appropriate for every error–The code is cluttered, but the program works better–You might still forget some error conditions3. Do the normal processing in one place, handle the errors in another (this is the Java way)–The code is at least reasonably uncluttered–Java tries to ensure that you handle every errorThe try statement•Java provides a new control structure, the try statement (also called the try-catch statement) to separate “normal” code from error handling: try { do the “normal” code, ignoring possible exceptions} catch (some exception) { handle the exception} catch (some other exception) { handle the exception}Exception handling is not optional•As in other languages, errors usually just cause your program to crash•Other languages leave it up to you whether you want to handle exceptions–There are a lot of sloppy programs in the world•Java tries to force you to handle exceptions–This is sometimes a pain in the neck, but–the result is usually a better programError and Exception are Objects•In Java, an error doesn’t necessarily cause your program to crash•When an error occurs, Java throws an Error object for you to use–You can catch this object to try to recover–You can ignore the error (the program will crash)•When an exception occurs, Java throws an Exception object for you to use–You cannot ignore an Exception; you must catch it–You get a syntax error if you forget to take care of any possible ExceptionThe exception hierarchy•Throwable: the superclass of “throwable” objects–Error: Usually should not be caught (instead, the bug that caused it should be fixed)–Exception: A problem that must be caught•RuntimeException: A special subclass of Exception that does not need to be caught•Hence, it is the Exceptions that are most important to us (since we have to do something about them)The Exception hierarchy IIThrowableError ExceptionRuntimeExceptionMust be caughtNeed not be caughtKinds of Exceptions•IOException: a problem doing input/output–FileNotFoundException: no such file–EOFException: tried to read past the End Of File•NullPointerException: tried to use a object that was actually null (RuntimeException)•NumberFormatException: tried to convert a non-numeric String to a number (RuntimeException)•OutOfMemoryError: the program has used all available memory (Error)•There are about 200 predefined Exception typesWhat to do about Exceptions•You have two choices:–You can “catch” the exception and deal with it•For Java’s exceptions, this is usually the better choice–You can “pass the buck” and let some other part of the program deal with it•This is often better for your own exceptions•Exceptions should be handled by the part of the program that is best equipped to do the right thing about themWhat to do about Exceptions II•You can catch exceptions with a try statement–When you catch an exception, you can try to repair the problem, or you can just print out information about what happened•You can “pass the buck” by stating that the method in which the exception occurs “throws” the exception–Example: void openFile(String fileName) throws IOException { ... }How to use the try statement•Put try {...} around any code that might throw an exception–This is a syntax requirement you cannot ignore•For each Exception object that might be thrown, you must provide a catch phrase: catch (exception_type name) {...}–You can have as many catch phrases as you need–name is a formal parameter that holds the exception object–You can send messages to this object and access its fieldsHow the try statement works•The code in the try {...} part is executed•If there are no problems, the catch phrases are skipped•If an exception occurs, the program jumps immediately to the first catch clause that can handle that exceptionOrdering the catch phrases•A try can be followed by many catches–The first one that can catch the exception is the one that will catch the exception•Bad: catch(Exception e) { ... }catch(IOException e) { ... }•This is bad because IOException is a subclass of Exception, so any IOException will be
View Full Document
Unlocking...