Exception Handling.ppt

Goals
 To learn how to throw exceptions
 To be able to design your own exception
classes
 To understand the difference between
checked and unchecked exceptions
 To learn how to catch exceptions
 To know when and where to catch an
exception

Separating Error Handling Code
 Traditional approach to error handling: method returns
error code
readFile {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file;
}
 What happens if
the file can't be opened?
the length of the file can't be determined?
enough memory can't be allocated?
if the read fails?
if the file can't be closed?
 To answer, you'd have to add a lot of code to do error
detection, reporting and handling

Separating Error Handling Code
errorCodeType readFile {
initialize errorCode = 0;
open the file;
if (theFileIsOpen) {
determine the length of the file;
if (gotTheFileLength) {
if (gotEnoughMemory) {
if (readFailed) {
errorCode = -1;
}
} else { errorCode = -2; }
close the file;
if (theFileDidntClose && errorCode == 0) {
errorCode = -4;
} else { errorCode = errorCode and -4; }
return errorCode;
}

The Alternative: Exception Handling
 Exceptions enable to write the main flow of code and deal with the,
well, exceptional cases elsewhere
readFile {
try {
open the file;
determine its size;
close the file;
}
catch (fileOpenFailed) { doSomething; }
catch (sizeDeterminationFailed) { doSomething; }
catch (memoryAllocationFailed) { doSomething; }
catch (readFailed) { doSomething; }
catch (fileCloseFailed) { doSomething; }
}

Propagating Errors Up the Call Stack
 Exceptions enable you to propagate error reporting up the call stack of
methods
method1 {
errorCodeType error;
error = call method2;
if (error) doErrorProcessing;
else proceed;
}
errorCodeType method2 {
error = call method3;
if (error) return error;
else proceed;
}
errorCodeType method3 {
error = call readFile;
if (error) return error;
else proceed;
}

Propagating Errors Up the Call Stack
 The Java runtime system searches backwards through
the call stack to find any methods that are interested in
handling a particular exception
method1 {
try {
call method2;
} catch (exception) { doErrorProcessing; }
}
method2 throws exception {
call method3;
}
method3 throws exception {
call readFile;
}

Grouping Error Types and Error
Differentiation
 Exceptions fall into
categories or groups.

Using Exceptions
 The throw clause
• Exceptions originate within a method or block of code
using the throw clause
throw someThrowableObject;
 The throws clause
• Specifies that the method can throw Exception(s)
public Object pop()
throws EmptyStackException {}

Using Exceptions
 The try block
• is used to wrap or enclose code where
exceptions may occur
 The catch block
• A method can catch an exception by providing
an exception handler for that type of
exception
• Typically, a catch block is created for each
type of exception that can occur.

The finally Clause
 Exception terminates current method
 Danger: Can skip over essential code
BufferedReader in =
new BufferedReader(
new FileReader(filename));
purse.read(in);
in.close();
 Must execute in.close() even if exception
happens
 Use finally clause for code that must be
executed "no matter what"

Example: Catching Exceptions
public void openAfile() {
try {
// Next two lines may generate an exception.
BufferedReader br =
new BufferedReader(
new FileReader ("aFile.txt"));
String s = br.readLine();
br.close();
// If no exceptions occur the following line
// will be executed.
System.out.println ("open File returned normally");
} catch (FileNotFoundException e) {
System.out.println ("Cannot find file to open!");
} catch (IOException e) {
System.out.println ("IOException: " + e);
} finally {
try { if (br != null) br.close();
} catch (IOException e) { };
}
}

Example: Declaring Exceptions
public static void main (String args[]) {
try {
openAfile();
} catch (FileNotFoundException e) {
System.out.println ("Cannot find file to open!");
} catch (IOException e) {
System.out.println ("IOException: " + e);
}
}
public static void openAfile()
throws FileNotFoundException, IOException {
// Next two lines may generate an exception.
BufferedReader br = new BufferedReader(
new FileReader("aFile.txt"));
String s = br.readLine();
br.close();
System.out.println("openAFile returned normally");
}

Exception Specification
 Java exceptions are of different types including
I/O Exceptions, runtime exceptions, and
exceptions of your own creation
• Runtime exceptions occur within the JRE, includes:
arithmetic exceptions, pointer exceptions, and
indexing exceptions
• The compiler does not require that you catch or specify
runtime exceptions
• Checked exceptions are not runtime exceptions and
are checked by the compiler

Best Practice
 Better to declare exception than to handle
it incompetently

Checked and Unchecked Exceptions

Designing Your Own Exceptions
if (amount > balance)
throw new InsufficientFundsException();
 Make it an unchecked exception – programmer could
have avoided it by calling getBalance()
 Extend RuntimeException and supply two
constructors
public class InsufficientFundsException
extends RuntimeException {
public InsufficientFundsException(){}
public InsufficientFundsException (String msg){
super(reason);
}
}

Example
 Program
• reads coin descriptions from file
• adds coins to purse
• prints total
 What can go wrong?
• File might not exist
• File might have data in wrong format
 Who can detect the faults?
• main method of PurseTest interacts with user
• main method can report errors
• Other methods pass exceptions to caller

The read method of the Coin class
 Distinguishes between expected and unexpected end of
file
public boolean read(BufferedReader in)
throws IOException {
String input =in.readLine();
if (input == null) // normal end of file
return false;
value = Double.parseDouble(input);
//may throw unchecked NumberFormatException
name = in.readLine();
if (name == null) // unexpected end of file
throw new EOFException("Coin name
expected");
return true;
}

The read method of the Purse class
 Unconcerned with exceptions
 Just passes them to caller
public void read(BufferedReader in)
boolean done = false;
while (! done) {
Coin c = new Coin();
if (c.read(in)) {
add(c);
} else {
done =true;
}
}
}

The readFile method of the Purse class
 finally clause closes files if exception happens
public void readFile(String filename)
BufferedReader in = null;
try {
in = new BufferedReader(
new FileReader(filename));
read(in);
} finally {
if (in != null)
in.close();
}
}

User interaction in main
 If an exception occurs, user can specify another file
name
boolean done = false;
String filename = args[0];
while (!done) {
try {
Purse myPurse = new Purse();
myPurse.readFile(filename);
System.out.println (
"total="+ myPurse.getTotal());
done = true;
} catch (IOException exception) {
System.out.println(
"Input/output error " + exception);
} catch (NumberFormatException exception) {
// error in file format
exception.printStackTrace();
}

Scenario
 PurseTest.main calls Purse.readFile
 Purse.readFile calls Purse.read
 Purse.read calls Coin.read
 Coin.read throws an EOFException
 Coin.read has no handler for the exception and
terminates immediately.
 Purse.read has no handler for the exception and
terminates immediately
 Purse.readFile has no handler for the exception and
terminates immediately after executing the finally
clause and closing the file.
 PurseTest.main has a handler for an IOException ,
a superclass of EOFException. That handler prints a
message to the user.

24
When to do what?
 If code that your code calls declares that it
can throw an Exception, what should you
do?
• Just throw the exception
• Catch the exception, report it, and recover
• Catch the exception, make a new, different
exception, and throw the new one
 When do you throw an Exception even if
no Exception was thrown to you?

25
When to re-throw the Exception
 If it’s more appropriate to deal with it at a
higher level of the code.
 If the exception means death to the
method it’s in. In other words, there’s no
reasonable way you can continue to
execute the code of this method.

26
When to catch it and recover
 If this is the appropriate place to report the
exception to the user, or log it, or whatever
you plan to do with it.
 If you can and should continue with this
method – for example if you can use a
default value, or try again.

27
When to catch it & throw your own
 If you’re sure the Exception is impossible
(your code is correct), so you don’t want to
have to declare it all the way up.
 On the other hand, if your code is
incorrect, you should not “hide” the
exception – you need to see it so that you
can fix your programmer error. Throw a
new RuntimeException, or your own sub
class of RunTimeException.

28
When to create your own Exception
 Sometimes you might create a new
Exception instance even though none of
your code threw one to you. You might be
the first “thrower” of this Exception.
 You should do this if your code detects
some error state that you cannot recover
from in this method – for example, an input
might be of an illegal value.

29
Use of Exceptions
 When handling critical events that may
jeopardize the system stability or worse.
• Obvious
 Feedback to the caller
• Should we throw an Exception when the user
inputs data with wrong syntax?
• What’s your point of view?
• Depends on the context?
• Is the fine line fuzzy and gray again?

30
Checked or Unchecked?
 If you create your own new Exception class, should it be
checked or Runtime?
 RuntimeExceptions are for programmer error
• i.e. your code is in a bad state. Stop program execution and go
debug. By the time a program reaches an end-user, it should never
throw these. The outermost layer of your program should gracefully
catch all Exceptions, even Runtimes and do something user-
friendly.
 Checked exceptions (all except RuntimeExceptions) are
for dealing with the outside world.
• If something about the input the user gave you is bad, or a file is
corrupt, or a database server is down, these are real-life things that
could happen, and your program should cope with them as
gracefully as possible.

31
Summary of Exceptions
 Catch and hide an exception if
• Can recover: (default value, user try again)
 Re-throw an exception if
• Irrecoverable to method
• More appropriate to handle elsewhere
 Throw new if
• You receive a checked exception and want to
throw an unchecked runtime exception

32
Summary of Exceptions
 When creating your own exception class
• Name it descriptively
• Place appropriately in class heirarchy
• If programmer error, make it a subclass of
RuntimeException (so it’s unchecked)
• If outside error (network, user, etc.), make it a
checked Exception

Exception Handling.ppt

More Related Content

Similar to Exception Handling.ppt (20)

Recently uploaded (20)

Exception Handling.ppt