Exceptions and Errors

Problems that arise in you code during execution

• error
  • very serious. Can not recover and go on.
    • OutOfMemoryError
    • NoSuchMethodError
• exception
  • may be able to recover and go on
  • at least give the user useful information and terminate gracefully
• Both are subclasses of Throwable

Exceptions

Exceptions come in two types

• checked exceptions
  • subclass of Exception
  • things the programmer can not control
    • IOException
• runtime exceptions
  • subclass of RuntimeException which is a subclass of Exception
  • also called unchecked exceptions
  • Should not happen in a well written priogram
    • NullPointerException
    • ArrayIndexOutOfBoundsException

Throwable Heirarchy

Checked Exceptions must be handled

• The compiler will complain if you do not handle a checked exception
• Use the throws clause in the method header

  public void readFile(String filename) 
                         throws FileNotFoundException
  {
     ...
  }

• Use a try/catch block

  public static void main(String[] args)
  {
     try
     {
        readFile("input.txt");
        ...
     }
     catch (FileNotFoundException e)
        System.out.println("Error: file not found: " 
           + "input.txt");
  

Handling Exceptions

• The process of exception handling is a search for a compenent handler
• Most of the time, you will not know what to do about an error
  • throw an exception
  • let someone closer to the user who knows what to do handle the problem
• Catch exceptions in the main method or other client

Catching a Runtime Exception

You can also catch Runtime exceptions

• Do not throw an exception when a simple if statement will work
• Good to catch user input errors

  try
  {
     String filename = . . .;
     FileReader reader = new FileReader(filename);
     Scanner in = new Scanner(reader);
     String input = in.next();
     int value = Integer.parseInt(input);
     . . .
  }
  catch (IOException exception)
  {
     exception.printStackTrace();
  }
  catch (NumberFormatException exception)
  {
     System.out.println("Input was not a number");
  }

• Notice we put everything into one try and have multiple catches
• A NullPointerException will not be caught

Class Question #1

Suppose the process method throws a EOFException. What gets printed?

try 
{
   process(filename)
}
catch (FileNotFoundException ex) 
{ 
   System.out.println("File not found");  //a
}
catch (IOException ex) 
{
   System.out.println("I/O error");  //b
}
catch (RuntimeException ex)
{ 
   System.out.println("Something went wrong"); //c
}

The finally Clause

• A exception terminates current method
• Danger: Can skip over essential code
• Example:
  

  reader = new FileReader(filename);
  Scanner in = new Scanner(reader);
  readData(in);
  reader.close(); // May never get here

• Want to execute reader.close() even if exception happens
• Use finally clause for code that must be executed no matter what

The finally Clause

Scanner in = new Scanner(reader);
try
{
   readData(in);
}
finally
{
   in.close(); 
}

• Executed when try block is exited in any of three ways:
  1. After last statement of try block
  2. After last statement of catch clause, if this try block caught an exception
  3. When an exception was thrown in try block and not caught

Java 7 Shortcut

try (Scanner in = new Scanner(file))
{   
   readData(in);
} // in.close called automatically—Scanner is AutoCloseable

Class Question #2

public void read(String filename) 
{
   Scanner in = null; //why asign a null value?
   try
   {
      in = new Scanner(new File(filename));
      process(in);
   }
   catch (IOException ex) { System.out.println("I/O Error"); }
   finally { in.close(); }
}

Which of the following is true if the file does not exist?

1. The message "I/O error" is printed
2. A FileNotFoundException is thrown to the caller of read
3. A NullPointerException is thrown to the caller of read
4. The read method returns without printing anything and without an exception

Where to handle an exception

Process of exception handling is a search for a competent handler

• Where an exception occurs is not usually the best place to handle it
• Think about BankAccount constructor
  • we consider negative opening balance an error
  • We could set it to 0 but
    • could cause unexpected things from the user’s point of view
  • can’t print a message
  • can throw an exception
• BankAccount does not know what to do about bad data.
• The client application may know
  • closer to the user
  • Knows if this is a console app, a GUI app
• throw an exception and let someone more knowledgeable handle the problem