Exceptions and Error Handling

Exceptions and Error Handling Michael Brockway January 16, 2015

Some causes of failures Incorrect implementation does not meet the specification. Inappropriate object request invalid index. Inconsistent or inappropriate object state arising through class extension. Not always programmer error Errors often arise from the environment; for instance, incorrect URL entered network interruption File processing is particularly error-prone: missing files lack of appropriate permissions.

Defensive Programming In Client-server interaction. Should a server assume that clients are well-behaved? or should it assume that clients are potentially hostile? Significant differences in implementation required. Issues How much checking by a server on method calls? How to report errors? How can a client anticipate failure? How should a client deal with failure? Arguments represent a major vulnerability for a server object. Constructor arguments initialize state. Method arguments often contribute to behaviour. Argument checking is one defensive measure.

Checking the Argument Eg check the key is being used before removing the item... public void removedetails(string key) { if (keyinuse(key)) { ContactDetails details = book.get(key); book.remove(details.getname()); book.remove(details.getphone()); numberofentries--; Server could return a diagnostic value...

Diagnostic value Eg check the key is being used before removing the item... public boolean removedetails(string key) { if (keyinuse(key)) { ContactDetails details = book.get(key); book.remove(details.getname()); book.remove(details.getphone()); numberofentries--; return true; //else return false;

Checking the return value What should client do with the diagnostic value? Is there a human user? who can solve the problem? The client object could test the return value attempt to recover or work around the error avoids program failure. The client could ignore the return value probably leads to program failure. An alternative approach is for a server function to throw an exception.

Exceptions A special language feature. special return value needed. Errors cannot be ignored in the client. The normal flow-of-control is interrupted. Specific recovery actions are encouraged. An exception is a problem that occurs when a program is running. Often a problem caused by circumstances outside the control of the program, such as bad user input. When an exception occurs the Java run-time creates an object of class Exception which holds information about the problem. A Java program itself may catch an exception. It can then use the Exception object to recover from the problem.

The Java exception mechanism A thrown exception involves transfer of control: processor stops executing current sequence of statements, and begins executing statements at a different point in the program. after the exception handler has run, the original sequence may resume. Exception is caught or handled by the code at the point to which control is transferred. There are two types of exception Checked exceptions subclass of Exception uses for anticipated failures, where recovery may be possible. Unchecked exceptions subclass of RuntimeException used for unanticipated failures, where recovery is unlikely.

Checked and Unchecked Exceptions Exception IOException CHECKED AWTException CHECKED RunTimeException all following subsclasses UNCHECKED ArithmeticException IllegalArgumentException NumberFormatException IndexOutOfBoundsException... others CHECKED

Checked and Unchecked Exceptions Unchecked exceptions are not checked by the compiler If thrown but not caught by a handler, the program terminates. Example: IllegalArgumentException Checked exceptions Some exception types are checked exceptions which means that a method must do something about them. The compiler checks each method to enforce this requirement. There are two things a method can do with a checked exception: handle the exception in a catch{ block; throw the exception to the caller of the method (which must have a handling mechanism of either of these kinds).

The throws clause A method in which a checked exception may be thrown must either provide code to handle the exception Use try {... catch(exception) {... as explained below or include a throws clause in its declaration: public void savetofile(string destinationfile) throws IOException {...... (body of method) In the latter case, when an exception occurs, control passes from the method to (the handling mechanism in) the method which called it.

Code can throw an exception Exceptions occur in the operating environment of a program; but they can be created by the code within the program An Exception should be used for an exceptional situation outside of the normal logic of a program Use one when the problem occurs in the middle of a complicated method that would be made even more complicated if it also had to handle unexpected data: for example, if (age < 16) { throw new Exception("Age is "+16); else {...... (other statements)

Another example /** * Look up a name or phone number and return the * corresponding contact details. * @param key The name or number to be looked up. * @return The details corresponding to the key, * or null if there are none matching. * @throws NullPointerException if the key is null. */ public ContactDetails getdetails(string key) { if(key == null) { throw new NullPointerException("null key in getdetails"); return book.get(key); (This is not compulsory, as the NullPointerException is unchecked.)

Throwing an exception When an exception is thrown by code, An exception object is constructed: just as when an exception occurs in program environment new ExceptionType("...") could be user-define sublass of Exception; The exception object is thrown: throw... Javadoc documentation: @throws ExceptionType reason

Argument checking (again) public ContactDetails getdetails(string key) { if (key == null) { throw new NullPointerException("null key in getdetails"); if(key.trim().length() == 0) { throw new IllegalArgumentException ( "Empty key passed to getdetails"); return book.get(key);

Preventing object creation //Constructor: public ContactDetails ( String name, String phone, String address) { if (name == null) { name = "" if (phone == null){ phone = ""; if (address == null) { address = ""; this.name = name.trim(); this.phone = phone.trim(); this.address = address.trim(); if (this.name.length() == 0 && this.phone.length() == 0) { throw new IllegalStateException( "Either the name or phone must not be blank.");

A throws example public class DoesIO { public static void main(string[] args) throws IOException { BufferedReader stdin = new BufferedReader ( new InputStreamReader(System.in)); System.out.println("Enter an integer:"); int num = Integer.parseInt(stdin.readLine()); System.out.printf("Square of %d is %d\n", num, num*num); This method does does not catch (handle) the IOException; it is instead thrown to the method that called this one. When the java runtime receives an exception from a program, it stops the program and prints a trace of what went wrong.

A multilayer throws example public class BuckPassing { public static void methodc() throws IOException { //... Some I/O code public static void methodb() throws IOException { //... methodc(); public static void methoda() throws IOException { //... methodb(); public static void main (String[] a) throws IOException { methoda();

A multilayer throws example An IOException occurs in methodc, which is called by methodb, which is called by methoda, called by main. It is thrown by methodc to methodb, which throws it to methoda, which throws is to main, which throws it to the java run-time. The stack trace looks like java.lang.ioexception: (some message) at some Java IO method at BuckPassing.methodC at BuckPassing.methodB at BuckPassing.methodA at BuckPassing.main

try { and catch { Usually we do not want to just throw exceptions up to calling methods; we want our code to catch the exception and handle it. To catch an exception: Put code that might throw an exception inside a try{ block. Put code that handles the exception inside a catch{ block. If a statement inside the try{ block throws an exception, the catch{ block immediately starts running. The remaining statements in the try{ block are skipped. After the catch{ block is executed, execution continues with the statement that follows the catch{ block. Execution does not return to the try{ block.

try { and catch { example boolean done = false; while (!done) { System.out.print("Enter file path: "); BufferedReader stdin = new BufferedReader ( new InputStreamReader(System.in)); String filename = stdin.readline(); try { addressbook.savetofile(filename); done = true; catch (IOException e) { System.out.println("Unable to save to " + filename); If savetofile throws an IOException, control transfers to the catch block; then resumes with the code after the catch block: in this case the end of the loop.

Another example try { num = Integer.parseInt(stdin.readLine()); System.out.printf("Square of %d is %d\n", num, num*num); catch (NumberFormatException ex) { System.out.println("You entered bad data."); System.out.println(ex.toString()); System.out.println("Run the program again."); System.out.println("Goodbye" ); Note that the exception object has a string representation containing a useful diagnostic message.

try { and catch { Syntax try{ // statements, some of which might throw an exception catch (SomeExceptionType ex){ // statements to handle this type of exception // optionally more catch blocks catch (AnotherExceptionType ex){ // statements to handle this type of exception // statements following the structure Statements in the try { block can include statements that always work statements that might throw an exception of one type or another There can be one or several catch{ blocks, or none. Each catch{ block describes the type of exception it handles.

Operation of try { and catch { The code statements in the try { run in sequence. If a statement causes an exception, control passes to the first matching catch { block for handling. Once the exception is handled, processing resumes with the statement after the last catch { block. If there is no catch { block matching the exception (or no catch { blocks at all), the exception is thrown up to the calling function, or the program terminates. Execution leaves the current method.

Example with multiple Exception types and catch { blocks public static void main ( String[] a ) throws IOException {...(code to set up stdin) try { System.out.println("Enter the numerator:"); num = Integer.parseInt(stdin.readLine()); System.out.println("Enter the divisor:"); div = Integer.parseInt(stdin.readLine()); System.out.printf("%d / %d = %d\n", num, div, num/div); catch (NumberFormatException ex ) { System.out.println("Problem with numeric input:"); System.out.println(ex); catch (ArithmeticException ex ) { System.out.println("Arithmetic exception"); System.out.println(ex);

Comments on the Example An IOException might occur in either readline() statement. There is no catch{ block for this type of exception, so the method has to say throws IOException. A NumberFormatException might occur in either call to parseint(). The input string is not a valid integer. The first catch{ block is for this type of exception. It will catch exceptions thrown from either parseint(). An ArithmeticException might occur if the user enters data that can t be used in an integer division: eg, a zero divisor. The second a catch{ block is for this type of exception.

The finally{ block If an IOExeption occurs in our program, it immediately loses control. The exception is thrown to the method that called it: in this case is the Java run time system. The program execution will halt. By using a finally{ block, you can ensure that some statements will always run, no matter how the try{ block was exited.

The finally{ block - Structure try{ // statements, some of which might throw an exception catch (SomeExceptionType ex){ // statements to handle this type of exception // optionally more catch blocks catch ( AnotherExceptionType ex ){ // statements to handle this type of exception finally{ // statements which will execute no matter // how the try block was exited. // Statements following the structure There can be only one finally block and it must come after the catch blocks.

Operation of try { and catch { with finally { The code statements in the try { run in sequence. If they all run without exception, control then passes to the finally { block, and then to the statements after the try/catch/finally structure. If a statement in the try { causes an exception, control passes to the first matching catch { block for handling. Once the exception is handled, control passes to the finally { block, then processing resumes with the statement after the try/catch/finally structure. If there is no catch { block matching the exception (or no catch { blocks at all), the finally { block is executed then the exception is thrown up to the calling function.

Omitting catch { blocks If there is a finally { block, catch { blocks may be omitted. Do this if you don t want to handle exceptions in this method, but you have a few statements that must execute no matter what before control is returned to the caller. This often happens if a method has a lock on some resource that it should give up before exiting. For example, if the method opens a file, it should (perhaps) close it before exiting.

Dealing with exceptions 1. Clean up and report the failure to caller (by throwing an exception). 2. Attempt to correct the situation that caused the exception, and try again. Here is an example. The constructor of java.io.filereader has the specification public FileReader (String filename) throws FileNotFoundException, SecurityException; So method using a FileReader to get some data from a file needs a specification like public void getsomedata () throws FileNotFoundException, SecurityException { FileReader in; in = new FileReader("DataFile");...

Dealing with exceptions ctd Some cleanup might be appropriate before throwing the exception updstairs : public void getsomedata () throws FileNotFoundException, SecurityException { FileReader in; try { in = new FileReader("DataFile");... catch (FileNotFoundException e) { // do cleanup... throw e; // throws it again to its caller catch (SecurityException e) { //cleanup throw e; // throws it again to its caller

Cleanup; Retrying A method cannot know how its caller will respond to the exception. The caller might be able to recover. It is important that method leave object in a consistent state (with all class invariants satisfied). The method should make sure that object is consistent before reporting failure to caller. The following code indicates how you might throw an exception up to the calling function only after a number of retries...

The FileReader example, ctd public void getsomedata () throws FileNotFoundException, SecurityException { FileReader in; boolean success = false; //Data file opened int trynum = 0, maxtries = 5; int delay = 5000; //msec while (!success) { try { trynum++; in = new FileReader("DataFile"); success = true;... catch (SecurityException e) { // we might expect if (trynumb < maxtries) //file lock to be Thread.sleep(delay); //removed shortly else throw e;

Exception Objects Exceptions are objects of class Exception or a subclass of it. They have member data and member methods, including: public void printstacktrace(): prints a stack trace: a list that shows the sequence of method calls up to this exception; public String getmessage(): returns a string that may describe what went wrong A catch{ block can use these methods to write an informative error message to the monitor

Application-defined Exceptions We can define our own exception classes to pass information to user/client. Example: throw exception if fail to get data: public class NoDataException extends Exception { public NoDataException () { //constructor super(); public NoDataException (String s) { //another constructor super(s);

Using NoDataException public void getsomedata () throws NoDataException { try { in = new FileReader("DataFile");... catch (FileNotFoundException e) { //cleanup throw new NoDataException ("File does not exist"); catch (SecurityException e) { //cleanup throw new NoDataException ("File cannot be accessed");

Another Application-defined Exception An exception class can pass state information from the method detecting the exception to the method that handles it: public class BadDataException extends Exception { private int linenumber; public BadDataException (int linenumber){ super(); this.linenumber = linenumber; public int linenumber() { return this.linenumber;

Error recovery Clients should take note of error notifications: check return values; do not ignore exceptions. Include code to attempt recovery: this will often require a loop. For example...

Error recovery // Try to save the address book. boolean successful = false; int attempts = 0; do { try { addressbook.savetofile(filename); successful = true; catch (IOException e) { System.out.println("Unable to save to " + filename); attempts++; if (attempts < MAX_ATTEMPTS) { filename = altfilename; while (!successful && attempts < MAX_ATTEMPTS); if(!successful) { [Report the problem and give up];

Summary Runtime errors arise for many reasons. An inappropriate client call to a server object. A server unable to fulfill a request. Programming error in client and/or server. Runtime errors often lead to program failure. Defensive programming anticipates errors in both client and server. Exceptions provide a reporting and recovery mechanism.