The Problem

1
The Problem

• Unexpected erroneous situations are often
  discovered by code which is NOT prepared to
  remedy the error.
• For example..
• String in JOptionPane.showInputDialog(enter
  side of square )
• side Integer.parseInt(in)
• area side side
• The parseInt method will not be able to convert
  an input string, such as abccd to a integer
  value !!
• SO WHAT SHOULD THIS METHOD DO??

2

• What should parseInt do if an integer value can
  not be determined from the parameter string??
• Prompt the user for another value??
• (System.out , JOptionPane,
  FileReader ??)
• Substitute a default value??
• Output an error message and cause program to
  exit??
• parseInt does not have the knowledge to make
  this decision there MAY be another method
  which does
• know how this should be handled.

3

• This is where Exception objects come in.
• Integer.parseInt cannot ignore the error.
• parseInt must do something. So it stops
  executing, creates an exception object (in
  particular a NumberFormatException object),
• and throws this back to the caller.
• WHY??? Perhaps the caller knows what the
  appropriate action is.
• Code to throw an exception object to indicate
  failure
• if (failure)
• throw new
• NumberFormatException(For input param)

4
If no method handles the exception, the
exception will eventually reach the main method
and crash picture of
console
5
Your code can throw exceptions
public class BankAccount public void
withdraw(double amount) if (amount
gt balance) throw new
IllegalArgumentException( "Amount exceeds
balance") balance balance - amount
...
6
(No Transcript)
7
Checked Exceptions

• Some exceptions are unavoidable -- and fatal to
  program
• file not found
• error in file
• Java puts these exceptions into a category
  called checked exceptions.
• That means that the compiler will check that
  your code either handles the situation, or
  specifies (declares) that it will occurs.
• Checked exceptions are subclasses of Exception
  that are not subclasses of RuntimeException

8
Checked and Unchecked Exceptions
9
Exception Specifications

• BufferedReader.readLine may throw IOException
• So the read method specifies this
• public class Coin public void
  read(BufferedReader in) throws IOException
• value Double.parseDouble(in.readLine())
  name in.readLine()
• ...

10
Exception Specifications

• Need to tag caller of Coin.read as well
• Stop at main or with handler (see below)
• Can have multiple exception typespublic void
  read()    throws IOException, ClassNotFoundExcept
  ion
• throws specifier not a sign of irresponsible
  programming
• Better to declare exception than to handle it
  incompetently

11
Designing Your Own Exception Types

• if (amount gt balance)    throw new
  InsufficientFundsException(. . .)
• Make it an unchecked exception--programmer could
  have avoided it by calling getBalance first
• Extend RuntimeException
• Supply two constructors

12
Designing Your Own Exception Types
previous start next
File Purse.java

public class InsufficientFundsException extends
RuntimeException public InsufficientFundsEx
ception()   public
InsufficientFundsException(String reason)
super(reason)

previous start next