290 likes | 410 Views
Chapter 13. Exceptional Programming. Three kinds of errors. Syntax errors : code that does not conform to the language specifications and must be corrected to compile at all ( bad programmer)
E N D
Chapter 13 Exceptional Programming
Three kinds of errors • Syntax errors: code that does not conform to the language specifications and must be corrected to compile at all (bad programmer) • Semantic errors: code that compiles and runs but the program does not do what was intended (bad algorithm) • Runtime errors: something about the data prevents continued operations (bad data)
Dealing with runtime errors • Ignore them • Log them • Warn the user/caller • Correct the error • Force the user/caller to handle the error • Abort the program
Dealing with runtime errors • Ignore them • Log them • Warn the user/caller • Correct the error • Force the user/caller to handle the error • Abort the program • Java forces error handling using exceptions
What to do? Throw up! • But then the calling program has to handle the exception
Types of Exceptions • All exceptions ultimately derive from the Throwable class, which extends Object • Exceptions are divided into two classes that extend Throwable: Exception and Error • Subclasses of Error are typically system errors (and generally fatal to the program) • Subclasses of Exception are typically program errors
Exception class subtypes • Exception is extended by many subclasses • Two commonly encountered examples are IOException and RuntimeException • RuntimeException has many subtypes, including ArithmeticException, NullPointerException, IndexOutOfBoundException, and IllegalArgumentException
Unchecked Exceptions • Exceptions come in two varieties: checked and unchecked • Unchecked exceptions can be thrown anywhere in the code • Consequently, Java does not require declaring these types of exceptions • Unchecked exceptions are Error and RuntimeExction
Checked Exceptions • All other exceptions are checked exceptions • Checked exceptions must be declared by the method they are thrown from • The calling method may ignore exceptions, but this is poor programming practice (but that does not mean it is uncommon) • Exceptions are declared using the throws keyword in the method declaration
Handling priority • An exception will be caught by the first catch block that matches the exeption • Therefore, a superclass catch block will handle an exception if placed before the subclass catch block • The subtype catch blocks should be placed before the more general supertype catch blocks
Overriding and Exceptions • If the supertype method does not throw a particular exception, a derived class cannot override the method and declare the additional exception
What’s in an exception? • getMessage() // the error message • toString() // concatenates the fully-qualified name of the exception class : getMessage() string • printStackTrace() // prints the stack trace to the console • getStackTrace() // returns an array of stack trace elements representing each call level
Last but not least: finally • The code in the finally block is executed no matter what happens in the try block • If no exception occurs, the finally block gets executed after the try block • If an exception occurs, the finally block gets executed after the exception’s catch block • If an uncaught exception occurs, the finally block gets executed
Re-throwing exceptions • A catch block can re-throw an exception • Typically this would happen if the handler discovered it could not fully process the exception for some reason • The exception then passes to the calling method and must be caught/handled there • The finally block will still execute…because it executes no matter what happens
Chaining exceptions • New exceptions can be created to add information to an existing exception • The two parameter constructor is used to create the new exception • The new exception is thrown similar to the way an exception is re-thrown • The calling method will receive the new exception with additional information
Custom Exceptions • Custom exceptions can be created by extending any suitable exception class in the hierarchy • Java provides a cornucopia of exceptions to cover a panoply of error conditions • There are legitimate situations where custom exception classes could be useful • Try to avoid being in any of those situations