Introduction to Computer Science I Topic 16: Exception Handling

Telecooperation/RBG

Technische Universität Darmstadt

Copyrighted material; for TUD student use only

Introduction to Computer Science ITopic 16: Exception Handling

Prof. Dr. Max MühlhäuserDr. Guido Rößling

Dr. G. RößlingProf. Dr. M. Mühlhäuser

RBG / Telekooperation©

Introduction to Computer Science I: T16

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

2




• 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) {

// …

}

...

Classification of errors

3

Lexical and syntactical errors are discovered and signaled by the compiler




Classification of errors

4

• 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




Error Handling, Bugs and Debugging

5

• 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




Error Handling, Bugs and Debugging

6

• 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




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

7




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 usersolution: repeat input

problem: wrong data in a file that can be ignored, e.g., uninterpretable image or audio signalsolution: Ignore the data

problem: network connection crashes solution: reconnect

8




Some typical exceptions

9

• 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!

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





10

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)






int count;

count = Integer.parseInt(args[1]);

// ...

}

11

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

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

code carries potential for multiple errors!




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

12




Overview





• Summary

13




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

14





• 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):

15

readFile { open the file; determine its size; allocate that much memory; read the file into memory; close the file;}





• 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

16





17

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;}





• 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!

18





• 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

19

Exception handling without language support is not feasible!Exception handling without language support is not feasible!




Overview





• Summary

20




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 backwards21




Throwing an exception

22

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




Throwing an exception

23

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

Will not be accepted by the compiler!




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?

Declaring potentially raised exceptions

24

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.




Calling methods that raise exceptions

25

// . . . car.start(); // . . . }}

public class Bar { // . . .

public void doSomethingWithCar(Car car) {

This code will not be accepted by

the compiler!

Reason: doSomethingWithCar calls a method that can eventually raise exceptions. These possible exceptions are ignored Program crash!




Handling raised exceptions

26

public class Bar { public void doSomethingWithCar (Car car) { // . . . try { car.start(); } catch (BatteryLowException bE) { // Exception handling } catch (SecurityException secEx) { // Exception handling } // . . . }}

try-block signals the willingness to catch and handle exceptions that occur in

statements within the block.

Catching and handling the

exceptions happens in catch-blocks.

1. possibility:calling method handles exceptions eventually raised by called methods




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 created27




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)!

28




Propagating errors in Java

29

public class Bar { public void doSomethingWithCar (Car car) throws BatteryLowException, SecurityException { // . . . car.start(); // . . . } }

2. possibility:Calling method further throws exceptions potentiallyraised by called methods along the call chain

2. possibility:Calling method further throws exceptions potentiallyraised by called methods along the call chain




Propagating errors in Java

30

public class Client { public static void main(String[] args) { // ... Car car = ...; Bar o2 = new Bar(); o2.doSomethingWithCar(car); // ... }}

30

o2: Bar :Car

o2.doSmthWithCar()

main

start()

Look up the first method with a catch-block for the raisedexception and continue with that code. If none is found,the program ends with an error message.

:Client




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.

31




Der finally-Block

32

public void test() { Switch sw = new Switch(); try { 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"); }}

Codeduplication




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

33

public void test() { Switch sw = new Switch(); try { sw.on(); // code that may throw exceptions } catch (BatteryLowException ebEx) { // ... } catch (SecurityException secEx) { // ... } finally { sw.off(); }}

sw is turned off independent of the concrete control flow of the program




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...

34




Overview





• Summary

35




Advantages of error handlingwith language support

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

36




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!

37

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; }}




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.

38

method1 { call method2;}

method2 { call method3;}

method3 { call readFile;}




2. Propagation of exceptions

39

method1 { errorCodeType error; error = call method2; if (error) doErrorProcessing; else proceed;} errorCodeType method2 {

errorCodeType error; error = call method3; if (error) return error; else proceed;}

errorCodeType method3 { errorCodeType error; error = call readFile; if (error) return error; else proceed;}




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

40

method1 { try { call method2; } catch (exception) { doErrorProcessing; }}

method2 throws exception { call method3;}

method3 throws exception { call readFile;}




3. Java’s exception type hierarchy• All exception types in Java inherit from the predefined

class java.lang.Throwable

41

"hard" VM failures; should

not be caught by a program

can be ignored; need not be declared or

handled

can be extended by programmer




The class Throwable

42

Throwable()

Throwable(String)

getMessage(): String

printStackTrace()

printStackTrace(PrintStream)

...

Throwable

creates a Throwable object with an error description

creates a Throwable object with an error description

returns theerror description

returns theerror description

prints the call stack at the time during the execution when the

Throwable object was created

prints the call stack at the time during the execution when the

Throwable object was created




Methods of class Exception

43

public class ExceptionMethods {


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();

}

}

}




Serious Exceptions: Error • Program cannot

continue, e.g., out of memory

44

It does not make sense to handle errors

Handling them is not enforced by the compiler.Will often lead to program crash




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 null-

reference, Violation of array boundaries…

45

These errors can be, but do not have to be handled




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 cannot check this statically

46


// possibly ArrayIndexOutOfBoundsException,

// NumberFormatException

Double doubleValue = Double.parseDouble(args[0]);

//possibly ArrayIndexOutOfBoundsException, // NumberFormatException

Integer intValue = Integer.parseInt(args[1]);

}




Checked exceptions

47

• Several predefined classes• FileNotFoundException• IOException• …

• Application specific exceptions: Defined by the programmer as (in)direct heirs of Exception.

• Checked exceptions are all exception types that inherit from Exception but not from RuntimeException




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

48

The scope of a method M is not only its own code, but also code of methods it

calls. This definition is recursive.




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.

49




Grouping exceptions

50

public void op1() { // ... catch (ArayIndexOutOfBoundsException invInd) { // do something with invInd } catch (NullPointerException npe) { // do something with npe } catch (NoSuchElementException eType) { // do something with eType }}

This version of op1 handles different array exceptions differently.

public void op1() { // ... catch (RuntimeException e) { // do something with e }}

Here all array exceptions are treated uniformly.




Grouping exceptions

51

public void op1() { // ... catch (RuntimeException e) { // do something with e }}

public void op1() { // ... catch (Exception 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

One can even treat ALL exceptions uniformly. NOT RECOMMENDED




Grouping exceptions

52

public void op1() { try { // ... } catch (RuntimeException e) {

// do something with e } catch (ArayIndexOutOfBoundsException e) {

// do something with invInd }}

public void op1() { try { // ... } catch (ArrayIndexOutOfBoundsException invInd) { // do something with invInd } catch (RuntimeException e) { // do something with e } }

The runtime system chooses the first catch block that handles the type of an exception or one of its super-types.

What happens if InvalidIndexExceptionis thrown in each of the versions of op1?




“Inheritance” of Exceptionspublic class CarException extends Exception {}public class NoGasoline extends CarException {}public class NoSpecialGasoline extends NoGasoline {}public class 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) { } }}

53

Dieser Code wird

vom Übersetzer so nicht

akzeptiert!




“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.

54




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

55

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




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.

56




Rethrowing an Exception

• 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.

57

catch (Exception e) {

System.out.println("An exception was thrown: "+e);

throw e;

// throw e.fillInStackTrace();

}




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); }

58




Overview





• Summary

59




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!

60




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

61




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

program62




Summary: flow of exception handling

63

Exception of type TEthrown in a try block

exit try block

execute instructions ofthe first such catch block

yes

Execute statementsof the (optional) finally block

catch block run withoutthrowing new exceptions?

execute statementsof the (optional) finally block

no

continue after try block

yes

propagate the newException object to enclosing try block

no

(catch-type =TE or catch-type superclass of TE) found?

Look-up catch blocks

Introduction to Computer Science I Topic 16: Exception Handling

Documents

Transcript of Introduction to Computer Science I Topic 16: Exception Handling