Transcript Introduction to Computer Science I

Technische Universität Darmstadt
Telecooperation/RBG
Introduction to Computer Science I
Topic 16: Exception Handling
Prof. Dr. Max Mühlhäuser
Dr. Guido Rößling
Copyrighted material; for TUD student use only
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Overview
• Errors and their classification
• Error handling without language support and its
problems
• Basics of error handling with language support in Java
• Advantages of error handling with language support in
Java
• Summary
Introduction to Computer Science I: T16
2
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Classification of errors
• Lexical errors: Wrong or unknown words are used in program code
// ...
int[] result = neu int[5];
result.size();
// ...
• Syntax errors: Wrong order of the words in program statements
...
move();
public static void main(String[] args) {
// …
}
...
Lexical and syntactical errors are
discovered and signaled by the compiler
Introduction to Computer Science I: T16
3
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Classification of errors
• Run-time errors: Any extraordinary event that occurs
during program execution and disturbs the ordinary
control flow  error termination
• Division by 0
• A non-existing graphical object shall be painted
• Intention errors: Program runs normally, but returns
wrong results
Introduction to Computer Science I: T16
4
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error Handling, Bugs and Debugging
• Dealing with errors is an important part of software development:
Quality assurance!
• The usual reaction to untreated exceptions is a program crash
–
This may be better than incorrect results that remain unnoticed for a long time
• Complex programs and distributed applications without any provision
for handling exceptions are inacceptable
– Telecommunication systems
– Guidance and control systems, e.g., for rockets or nuclear plants
• Programs that treat errors gracefully are called robust
Introduction to Computer Science I: T16
5
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error Handling, Bugs and Debugging
• This lecture  catching and resolving runtime errors
– Heavy-weigth vs. light-weight errors
• Next lecture  Intention errors: test or verify that the software
does what it is supposed to do
• Bug: name for all types of all program errors
– Origin: A dead moth (not really a “bug”) in a relais caused a
malfunction.
– Usually hard to find, „100% bug free“ is close to impossible
• Debugging = searching for errors
• Both words go back to Grace Hopper
Introduction to Computer Science I: T16
6
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Heavyweight runtime errors
• Two types of heavyweight programming errors:
– System faults: faults in the Java VM, lack of free memory, …
• Not the application programmer’s fault
• Cannot be caught and lead directly to a program
crash
– Programming faults after which a continuation is not
possible
• A required class is not available
Introduction to Computer Science I: T16
7
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Lightweight errors
• Lightweight errors (also called exceptions) are errors which can
be caught in the program; continuing the program is possible
after fixing the error
problem: input of a wrong file name by the user
solution: repeat input
problem: wrong data in a file that can be ignored, e.g.,
uninterpretable image or audio signal
solution: Ignore the data
problem: network connection crashes
solution: reconnect
Introduction to Computer Science I: T16
8
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Some typical exceptions
public void printPerson() {
Person aPerson = null;
printName(aPerson);
// …
}
public void printName(Person p) {
System.out.println(p.name);
}
• Problem: sending a message to "null"
• Result: NullPointerException
• Access to a method or instance variable of a non-existing
object (null)
• Effectively there was an attempt to access "null.name"
• The existence of the object should be checked before access!
Introduction to Computer Science I: T16
9
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Some typical exceptions
int[] matriculationNumber = new int[27];
for (int i = 0; i <= 27; i++)
System.out.println(matriculationNumber[i]);
• Problem: illegal array access with i == 27
• Result: ArrayIndexOutOfBoundsException
• Only positions i with 0 <= i < array.length are valid
• Especially tricky is the case of call parameters
• Always test how many arguments were passed
(args.length)
Introduction to Computer Science I: T16
10
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Some typical exceptions
public static void main(String[] args) {
int count;
count = Integer.parseInt(args[1]);
// ...
}
code carries potential for multiple errors!
Problem 1: illegal array access if no parameters were passed to
the program. In this case, args has no elements - accessing
args[1] fails
Result 1: ArrayIndexOutOfBoundsException
Problem 2: Attempt to parse a non-number if args[1] is e.g.,
"Hello". Text cannot be transformed into a number
Result 2: NumberFormatException
Introduction to Computer Science I: T16
11
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Exception handling
• Exception handling can be done…
– without language support
• In languages such as C or Pascal
– with language support
• In languages such as Ada, Smalltalk, Java
• In the following, we will:
– Consider the problems of error handling
without language support
– Introduce error handling with dedicated
language support and its advantages in Java
Introduction to Computer Science I: T16
12
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Overview
• Errors and their classification
• Error handling without language support and its
problems
• Basics of error handling with language support in Java
• Advantages of error handling with language support in
Java
• Summary
Introduction to Computer Science I: T16
13
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error handling without language support
• Two possibilities for error signaling:
– Program crash (!) – The extreme case are
functions that do not signal errors at all but
simply terminate the program:
• E.g., access to a non-existing file led to a program crash in
older versions of Pascal
– Errors are signaled in many languages by means
of unusual return codes (e.g., –1 instead of a
positive number)
• Catching and handling of errors:
– Error handling is ignored by the programmer
– Errors are handled by means of conditional logic
Introduction to Computer Science I: T16
14
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error handling without language support
• We consider the following case:
–
–
Errors are signaled by unusual return values
They are handled by conditional logic
• Problem: No separation of normal code from error handling
• Suppose we had a function that reads a whole file from hard
disk into memory (in pseudo code):
readFile {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file;
}
Introduction to Computer Science I: T16
15
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error handling without language support
• The function seems simple at first sight…
• But it ignores all possible errors:
– File cannot be opened
– Length of file cannot be determined
– Not enough space in memory to read the file
– Reading from the file fails
– File cannot be closed
• Including appropriate error handling may result in
serious code bloat, as seen on the next slide
Introduction to Computer Science I: T16
16
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error handling without language support
errorCodeType readFile {
initialize errorCode = 0;
open the file;
if (theFileIsOpen) {
determine the length of the file;
if (gotTheFileLength) {
allocate that much memory;
if (gotEnoughMemory) {
read the file into memory;
if (readFailed) { errorCode = -1; }
} else { errorCode = -2; }
} else { errorCode = -3; }
close the file;
if (theFileDidNotClose && errorCode == 0) {
errorCode = -4;
} else { errorCode = errorCode && -4; }
}
else { errorCode = -5; }
return errorCode;
}
Introduction to Computer Science I: T16
17
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error handling without language support
• Including error handling results in 29 instead of 7
lines of code - a factor of nearly 400%!
• The main purpose of the code gets lost in the
code for the discovery, signaling and treating of
errors.
• The logic flow of the code is hard to follow,
which makes finding programming errors harder
– Is the file closed in case we are out of
memory?
• It gets even worse if the function should be
modified later!
Introduction to Computer Science I: T16
18
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Error handling without language support
• Conclusion: trade-off between reliability and
readability
– If errors are handled, program structure gets
complex (e.g. many “if” statements)
– If errors are ignored, the reliability is lost
Exception handling without language
support is not feasible!
Introduction to Computer Science I: T16
19
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Overview
• Errors and their classification
• Error handling without language support and its
problems
• Basics of error handling with language support in Java
• Advantages of error handling with language support in
Java
• Summary
Introduction to Computer Science I: T16
20
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Exception handling in Java
• Exceptions are Java objects
• The Java compiler enforces the treatment of certain types of errors
• If an error occurs while executing a method:
– This method [or the runtime system] creates an exception
object. This object contains information about the type of the error,
the state of the program at the time of the error, etc.
– Exception raised: control and the created exception object are
yielded to the runtime system
– The runtime system looks for code that can handle the raised
(thrown) exception
• Candidates for providing handlers are methods in the call-chain of
the method where the error occurred
• The call chain is searched backwards
Introduction to Computer Science I: T16
21
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Throwing an exception
public class Car {
public void start() {
// …
// battery might be (close to) empty
// driver might not be authorized
}
}
The battery might be (close to) empty. In order to avoid a
program crash, an exception shall be thrown 
BatteryLowException
The driver may not be authorized for this car
 Exception: SecurityException
Introduction to Computer Science I: T16
22
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Throwing an exception
public class Car {
// ...
public void start() {
// ...
if (batteryLevel <= 5)
throw new BatteryLowException(
"Battery is empty");
if (!driver.isAuthorized())
throw new SecurityException(
"No access rights");
// start the car
}
}
Throw-Statement: "throw" Exception-Object.
Constraint: Exception-Object must be of a subtype of
type Exception (more in a minute).
Almost always created in place by means of new
Introduction to Computer Science I: T16
23
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Declaring potentially raised exceptions
public class Car {
public void start()
throws BatteryLowException, SecurityException {
// . . .
// start car
} The method has to declare thrown exceptions in its signature.
}
They belong to a method’s signature just like the return type.
Declaration syntax: "throws" <Exception-List>
<Exception-List> = <Exception-Name>
{"," <Exception-List>}.
• We can declare several exceptions to be thrown
• The Java compiler checks if the declaration is correct
– Can exceptions occur which are not declared or will not be caught?
Introduction to Computer Science I: T16
24
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Calling methods that raise exceptions
public class Bar {
// . . .
public void doSomethingWithCar(Car car) {
// . . .
car.start();
// . . .
}
}
Reason: doSomethingWithCar calls a method that can eventually
raise exceptions.
These possible exceptions are ignored  Program crash!
Introduction to Computer Science I: T16
25
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Handling raised exceptions
public class Bar {
public void doSomethingWithCar (Car car) {
// . . .
try-block signals the willingness to catch and
try {
handle exceptions that occur in statements
car.start();
within the block.
}
catch (BatteryLowException bE) {
// Exception handling
}
catch (SecurityException secEx) { Catching and handling
the exceptions happens
// Exception handling
in catch-blocks.
}
// . . .
}
}
1. possibility:
calling method handles exceptions eventually raised by called methods
Introduction to Computer Science I: T16
26
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Handling raised exceptions
• Each catch block declares a formal parameter
– Example: catch(SecurityException e)
• The parameter type determines the exception type that the
catch-block catches and handles
– Here: SecurityException
• The parameter (here: e) is a local variable in the catch-block
– Allows references to the exception object to handle within the
catch block
– Allows access to methods and attributes of the exception object
• Exceptions are ordinary Java objects, defined in ordinary
Java classes
• Typical method calls:
– e.getMessage() – accesses the error text
– e.printStackTrace() – prints out the call stack when
e was created
Introduction to Computer Science I: T16
27
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Handling several exceptions of a block
How to handle the case when several exceptions are thrown by
the statements of a statement block?
• There can be several catch blocks for one try block!
– Individual statements that potentially throw several
exceptions are also put in a try block.
• The first appropriate catch block will be executed
– Attention should be paid when exceptions are in an
inheritance hierarchy (more in a minute)!
Introduction to Computer Science I: T16
28
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Propagating errors in Java
public class Bar {
public void doSomethingWithCar (Car car)
throws BatteryLowException, SecurityException {
// . . .
car.start();
// . . .
}
}
2. possibility:
Calling method further throws exceptions potentially
raised by called methods along the call chain
Introduction to Computer Science I: T16
29
Propagating errors in Java
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
public class Client {
public static void main(String[] args) {
// ...
Car car = ...; Bar o2 = new Bar();
o2.doSomethingWithCar(car);
// ...
}
}
:Client
main
o2: Bar
:Car
o2.doSmthWithCar()
start()
Look up the first method with a catch-block for the raised
exception and continue with that code. If none is found,
the program ends with an error message.
Introduction to Computer Science I: T16
30
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Ensuring execution of certain actions
How can one ensure that certain actions are
always executed?
• Problem: In programs with exceptions, there are several
possibilities to exit the program.
– Sometimes the execution of certain actions must be
guaranteed, no matter whether an exception occurred or not
• Example: Writing to a successfully opened file
– The file should always be closed, whether the data was
written or not.
Introduction to Computer Science I: T16
31
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Der finally-Block
public void test() {
Switch sw = new Switch();
try {
Code
duplication
sw.on();
// code that may throw exceptions
sw.off();
} catch (BatteryLowException ebEx) {
sw.off();
// don’t do this; it duplicates code
System.err.println("Caught BatteryLowException");
} catch (SecurityException secEx) {
sw.off();
// don’t do this; it duplicates code
System.err.println("Caught SecurityException");
}
}
Introduction to Computer Science I: T16
32
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
Ensuring execution of certain actions
©
• Java provides a finally block
• The statements within the finally blocks are always
executed
– After finishing the try blocks if no exception has occurred
– After finishing the catch blocks if an exception was thrown
public void test() {
Switch sw = new Switch();
try {
sw.on();
// code that may throw exceptions
} catch (BatteryLowException ebEx) {
// ...
} catch (SecurityException secEx) {
// ...
sw is turned off
}
finally {
independent of the
sw.off();
concrete control flow
}
}
the program
Introduction to Computer Science I: T16
of
33
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Advantages of the finally block
• The statements within the finally block are
executed independent of exception occurrence
– There is no duplicated code, which must be executed
whether there is an exception or not.
• Attention:
– Statements in the finally block can also throw
exceptions!
• Closing files or network connections fails,
NullPointerException, ...
– Handling the exceptions in finally blocks is done in the
same way as in any other block...
Introduction to Computer Science I: T16
34
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Overview
• Errors and their classification
• Error handling without language support and its
problems
• Basics of error handling with language support in Java
• Advantages of error handling with language support
in Java
• Summary
Introduction to Computer Science I: T16
35
Advantages of error handling
with language support
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
1. Separation of the error handling from “normal”
logic
2. Propagation of errors along the dynamic call chain
3. Distinction and grouping of different types of
errors
4. Compiler ensures that certain types of errors get
handled
Introduction to Computer Science I: T16
36
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
1. Separation of error handling
• Java’s exception
handling constructs
enable separation of
normal code and error
handling
• Attention! Separation of
exception handling does
not save the work of
discovering, signaling
and recovering from
errors
– The separation is the
advantage!
void readFile() {
try {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file;
} catch (FileOpenFailed) {
doSomething;
} catch (sizeDeterminationFailed) {
doSomething;
} catch (memoryAllocationFailed) {
doSomething;
} catch (readFailed) {
doSomething;
} catch (fileCloseFailed) {
doSomething;
}
}
Introduction to Computer Science I: T16
37
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
2. Propagation of exceptions
• Suppose readFile is the fourth method in a call
chain: method1, method2, method3, readFile
– Suppose method1 is the only method interested in
handling errors occurring in readFile
• Without language support for exceptions, method2
and method3 must propagate the error codes of
readFile until they reach method1.
method1 {
call method2;
}
method2 {
call method3;
}
Introduction to Computer Science I: T16
method3 {
call readFile;
}
38
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
2. Propagation of exceptions
method1 {
errorCodeType error;
error = call method2;
if (error)
doErrorProcessing;
else
proceed;
}
errorCodeType method3 {
errorCodeType error;
error = call readFile;
if (error)
return error;
else
proceed;
}
errorCodeType method2 {
errorCodeType error;
error = call method3;
if (error)
return error;
else
proceed;
}
Introduction to Computer Science I: T16
39
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
2. Propagation of exceptions
• In contrast to this, the runtime system of Java automatically
searches backwards through the call chain for methods that can
handle the exceptions
method1 {
try {
call method2;
} catch (exception) {
doErrorProcessing;
}
}
method2 throws exception {
call method3;
}
method3 throws exception {
call readFile;
}
Introduction to Computer Science I: T16
40
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
3. Java’s exception type hierarchy
©
• All exception types in Java inherit from the predefined class
java.lang.Throwable
"hard" VM failures;
should not be
caught by a
program
can be ignored; need not
be declared or handled
can be extended
by programmer
Introduction to Computer Science I: T16
41
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
The class Throwable
creates a Throwable object with
an error description
Throwable
returns the
error description
Throwable()
Throwable(String)
getMessage(): String
printStackTrace()
printStackTrace(PrintStream)
...
prints the call stack at the
time during the execution
when the Throwable object
was created
Introduction to Computer Science I: T16
42
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Methods of class Exception
public class ExceptionMethods {
public static void main(String[] args) {
try {
throw new Exception("Here’s my Exception");
} catch (Exception e) {
System.out.println("Caught exception");
System.out.println("e.getMessage(): "+e.getMessage());
System.out.println("e.toString(): "+e.toString());
System.out.println("e.printStackTrace():");
e.printStackTrace();
}
}
}
Introduction to Computer Science I: T16
43
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Serious Exceptions: Error
• Program cannot
continue, e.g., out
of memory
It does not make sense to
handle errors
Handling them is not
enforced by the compiler.
Will often lead to program
crash
Introduction to Computer Science I: T16
44
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Unchecked exceptions: RuntimeException
• Runtime exceptions are errors that can occur
everywhere in the program, depending on run-time
conditions:
– Trying to call an operation on a variable with a nullreference, Violation of array boundaries…
These errors can
be, but do not
have to be handled
Introduction to Computer Science I: T16
45
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Unchecked exceptions: RuntimeException
• Enforcing the programmer to handle run-time exceptions would
render a program unreadable
–
Such errors can occur everywhere…
• To handle NullPointerException, a catch block
would be needed for every function call:
• Even if the programmer is sure that each variable in the
program contains a valid object!
• The Compiler can not test this statically
• The compiler
this staticallyargs) {
public
staticcannot
void check
main(String[]
// possibly ArrayIndexOutOfBoundsException,
//
NumberFormatException
Double doubleValue = Double.parseDouble(args[0]);
//possibly ArrayIndexOutOfBoundsException,
//
NumberFormatException
Integer intValue = Integer.parseInt(args[1]);
}
Introduction to Computer Science I: T16
46
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Checked exceptions
• Checked exceptions are all exception types that inherit
from Exception but not from RuntimeException
• Several predefined classes
• FileNotFoundException
• IOException
• …
• Application specific exceptions:
Defined by the programmer as
(in)direct heirs of Exception.
Introduction to Computer Science I: T16
47
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Checked exceptions
• For certain exceptions the compiler enforces that checked
exceptions are handled
• A method must either
– catch checked exceptions occurring in its scope, or
– Pass the exceptions along the call chain and declare
them with a throws-clause
The scope of a method M is not only its
own code, but also code of methods it calls.
This definition is recursive.
Introduction to Computer Science I: T16
48
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Grouping exceptions
• Exceptions are ordinary Java objects defined in ordinary
Java classes and have their own inheritance hierarchy
• As such, one can define specialization / generalization
relations between different exception types
• An IndexOutOfBoundsException is thrown if an index is
out of scope
– ArrayIndexOutOfBoundsException is a subclass that
applies to array accesses
– “Out of scope”: index is negative or greater than or equal to
the array size
• The programmer of a method can choose to handle more or
less specific exceptions.
Introduction to Computer Science I: T16
49
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Grouping exceptions
This version of op1 handles
public void op1() {
different array exceptions
differently.
// ...
catch (ArayIndexOutOfBoundsException invInd) {
// do something with invInd
}
catch (NullPointerException npe) {
// do something with npe
}
catch (NoSuchElementException eType) {
// do something with eType
}
}
public void op1() {
}
// ...
catch (RuntimeException e) {
// do something with e
}
Here all array exceptions
are treated uniformly.
Introduction to Computer Science I: T16
50
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Grouping exceptions
public void op1() {
// ...
catch (RuntimeException e) {
// do something with e
}
}
One could also use conditional logic to distinguish
between different subtypes of
RuntimeException. But the first version is:
• Better documented
• Easier to maintain
public void op1() {
}
// ...
catch (Exception e) {
// do something with e
}
Introduction to Computer Science I: T16
One can even treat
ALL exceptions
uniformly. NOT
RECOMMENDED
51
Grouping exceptions
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
public void op1() {
try {
// ...
}
catch (ArrayIndexOutOfBoundsException invInd) {
// do something with invInd
}
catch (RuntimeException e) {The runtime system chooses the
// do something with e
first catch block that handles the
}
}
type of an exception or one of its
super-types.
public void op1() {
}
try {
// ...
}
catch (RuntimeException e) {
// do something with e
}
catch (ArayIndexOutOfBoundsException e) {
// do something with invInd
}
What happens if InvalidIndexException
is thrown in each of the versions of op1?
Introduction to Computer Science I: T16
52
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
“Inheritance” of Exceptions
public
public
public
public
class
class
class
class
CarException extends Exception {}
NoGasoline extends CarException {}
NoSpecialGasoline extends NoGasoline {}
BadWeather extends Exception {}
public class Car {
public void start() throws NoGasoline { … }
public void stop() throws CarException { … }
}
public class SportsCar extends Car {
public void start() throws NoSpecialGasoline { … }
public void stop() throws BadWeather { … }
public static void main(String[] args) {
try {
new SportsCar().start();
} catch (NoSpecialGasoline e) { }
}
}
Introduction to Computer Science I: T16
53
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
“Inheritance” of Exceptions
• Rule 1:
– If method x in the base class throws an exception,
the overridden method x in a subclass may throw
the same exception, or one derived from it.
• Rule 2:
– The overridden subclass method cannot throw an
exception that is not a type/subtype of an
exception thrown by the method from its ancestor.
Introduction to Computer Science I: T16
54
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Constructors and Exceptions
• We cannot have anything before the base-class
constructor call using super(), not even a try block
• Exceptions of a base-class constructor must be declared
in the signature of the derived-class constructor
public class Car {
public Car() throws NoGasoline {}
}
public class SportsCar extends Car {
public SportsCar throws NoGasoline {
super(); //maybe throws a NoGasoline exception
//...
NoGasoline may not be replaced
}
by NoSpecialGasoline
}
Introduction to Computer Science I: T16
55
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
What’s in a name?
• Name of the exception is typically the
most important thing about it.
• Names tend to be long and descriptive.
• Code for the exception class itself is
usually minimal.
• Once you catch the exception you
typically are done with it.
Introduction to Computer Science I: T16
56
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Rethrowing an Exception
catch (Exception e) {
System.out.println("An exception was thrown: "+e);
throw e;
// throw e.fillInStackTrace();
}
• Perform anything you can locally, then let a global
handler perform more appropriate activities.
• fillInStackTrace records within this Throwable
object information about the current state of the
stack frames for the current thread.
Introduction to Computer Science I: T16
57
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Checking for expected exceptions in JUnit 4
• Do you remember our calculator using JUnit in T12?
– We had a test method „divideByZero()“
– We expect this test method to throw an ArithmeticException
• We want to be able to check for this expected exception
– If it is thrown, the test has been passed (expected exception)
– If it is not thrown, the test shall fail
• How can we “check” and catch the exception using JUnit?
• We use parameter for the @Test annotation
– @Test(expected=ExceptionType.class)
• In our example:
@Test(expected = ArithmeticException.class)
public void divideByZero() {
calculator.divide(0);
}
Introduction to Computer Science I: T16
58
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Overview
• Errors and their classification
• Error handling without language support and its
problems
• Basics of error handling with language support in Java
• Advantages of error handling with language support in
Java
• Summary
Introduction to Computer Science I: T16
59
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Summary
•
•
Each program can potentially produce errors
Java has explicit support for error handling
– Errors: Heavyweight problems  cannot be handled
– Exceptions are problems that can be handled
•
There are basically three approaches to exceptions:
– Declaration and propagation of exceptions via „throws“ and
exception type in the method head
– Handing of exceptions in try…catch blocks of the method
–
Runtime exceptions can be ignored, but they can also be
handled!
Introduction to Computer Science I: T16
60
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Summary
• Exception handling happens in try...catch
– Statements that can create exceptions (mostly method calls) are put in
a try block
– Possible exceptions are handled in catch blocks
– Each catch block handles one exception type
– The concrete type is declared in the parameter of the catch block
• Searching for an appropriate catch happens top down
– The first fitting catch block will be used
– When ordering the catch blocks one should take into consideration the
exception inheritance hierarchy!
• Statements in finally block will always be executed
– No matter whether an exception was thrown or not
– Ideal for cleaning up, e.g., closing open files
Introduction to Computer Science I: T16
61
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
©
Summary: Control Flow for Exceptions
How does the control flow look like in case of an error?
1. Creation of an appropriate exception object
•
•
The exception object describes the problem and potentially the cause
• Current class (name!), potentially the code line, problem
description (text)
The creation of the exception object can happen...
• „automatically“ by the runtime system (e.g.,
NullPointerException)
• By method calls (e.g., FileNotFoundException)
• By the programmer by means of „throw new XXX()“
2. The runtime system searches for a fitting catch
•
•
•
starting with the current block up to the current method…
continuing in the method that called the method at hand…
...and so on in the call chain, eventually up to the start of the
program
Introduction to Computer Science I: T16
62
Dr. G. Rößling
Prof. Dr. M. Mühlhäuser
RBG / Telekooperation
Summary: flow of exception handling
©
Exception of type TE
thrown in a try block
exit try block
Look-up catch blocks
(catch-type =TE or catch-type
superclass of TE) found?
no
yes
execute instructions of
the first such catch block
execute statements
of the (optional) finally block
Execute statements
of the (optional) finally block
catch block run without
throwing new exceptions?
no
yes
continue after try block
Introduction to Computer Science I: T16
propagate the new
Exception object to
enclosing try block
63