1Exception Handling

• Introduction to Exception Handling• Exception Handling in PLs

– Ada– C++– Java

• Sebesta Chapter 14

2Why Exception Handling?

• No exception handling– Unchecked errors abort the program– Clutter program with if-clauses checking for errors– Use the return value to indicate errors– Pass an error-label parameter in all subprograms– Pass an errors handling subprogram to all subprograms

• With exception handling– Programs can catch exceptions, handle the problems and continue– Programmers are encouraged to consider all possible errors– Exception propagation allows for reuse of exception handling code

3Basic Concepts

• An exception– An exceptional state in program execution, typically an error

• Exception handling – Built-in mechanism for special flow control when exception occurs

• Exception handler– Code unit that handles an exception

• An exception is raised (or thrown)– When the associated exceptional event occurs

4Design Issues

• How and where are exception handlers specified?• What is the scope of an exception handler?• How is an exception event bound to an exception handler?• Is the exception info available in the handler?• Where does control go at the end of an exception handler?• Is finalization supported?

• Can user define her own exceptions and how?• Should there be default exception handlers?• Can built-in exceptions be explicitly raised?• Are hardware errors exceptions that can be handled?• Are there any built-in exceptions?• Can exceptions be disabled and how?

5Exception Handling Control Flow

6Exception Handling in Ada

• An exception handler is– a subprogram body, or – a package body, or– a task, or – a block

• Exception handlers do not have parameters– They are usually with the code where an exception can be

raised

• Handlers are at the end of the block in which they occur

7Exception Handlers Syntax

• Handler formwhen exception { | exception } => statements

...

[when others => statements]

• exception formexception_name | others

8Propagation of Exceptions

• If exception is raised in a unit without a handler for that exception, the unit is terminated

• Then, the exception is propagated– From a procedure

• to the caller

– From a block• to parent scope

– From a package body • to the declaration part of the declaring unit

– In a task • No propagation, just mark it "Completed"

• If the unit where an exception is propagated to doesn't handle it, that unit is terminated, too

9Other Syntax

• User-defined exceptions formexception_name_list : exception;

• Raising exceptions formraise [exception_name]

– If the exception name is omitted, the same exception is propagated

• Exception conditions can be disabled withpragma SUPPRESS(exception_list)

10Predefined Exceptions

• CONSTRAINT_ERROR – index constraints, range constraints, etc.

• NUMERIC_ERROR – illegal numeric operation (overflow, division by zero, etc.)

• PROGRAM_ERROR – call to a subprogram whose body has not been elaborated

• STORAGE_ERROR – system heap overflow

• TASKING_ERROR – Some tasks' error

11Evaluation of Ada's Exception Handling

• Reflects the state-of-the-art in PL design in 1980

• A significant advance over PL/1

• Ada was the only widely used language with exception handling before it was added to C++

12Exception Handling in C++

• Exception handling was added in 1990

• Design is based on CLU, Ada, and ML

• Syntaxtry { -- code that may raise an exception} catch (formal parameter) { -- handler code} catch (formal parameter) { -- handler code

…}

13catch Function

• catch is an overloaded name of all handlers– The formal parameter of each catch must be unique

• The formal parameter doesn't need to be a variable– It can be a type name to distinguish it from others

• The formal parameter can supply the handler with information about the exception

• If the formal parameter is an ellipsis, it handles all exceptions not yet handled

• After a handler is executed, control flows to the first statement after the sequence of catches

• An unhandled exception is propagated to the caller• The propagation continues to the main function• If no handler is found, the default handler is called

14Throwing Exceptions

• Exceptions are raised explicitly bythrow [expression];

• A throw with no operand re-raises the exception– It can only appear within a handler

• The type of the expression disambiguates the handlers

15Other Design Choices

• All exceptions are user-defined

• Exceptions are neither specified nor declared

• The default handler unexpected terminates the program– unexpected can be redefined by the user

• A function can list the exceptions it may raise

• A function can raise any exception (the throw clause)– No specification is required

16Evaluation of Exception Handling in C++

• Advanced compared to Ada

• However, some weird design choices

• Reliability– Hardware- and system software-exceptions can't be handled

• Readability– Exceptions are not named– Exceptions are bound to handlers via the type of the parameter

17Exception Handling in Java

• Based on that of C++

• More OOP-compliant

• All exceptions are objects of subclasses of the Throwable class

18Classes of Exceptions

• Superclasse Throwable has two subclasses• Error

– System events such as heap overflow– User programs aren't required to handle these– Usually they don't handle them

• Exception– User-defined exceptions are usually subclasses– Has rich subtree of predefined subclasses

• NullPointerException, IOException, ArrayIndexOutOfBoundsException, …

• Typically, user programs must handle these

19Java Exception Handlers

• try clause is exactly like in C++

• catch clause is like in C++– But every catch must have a declared named parameter whose

type is a subclass of Throwable

• Exceptions are thrown as in C++ with throw, but an object must be thrown– It must bean instance of a subclass of Throwable

• An exception is bound to the 1st handler whose parameter type matches the thrown object – It has the same class or is a its superclass

• A handler that catches a Throwable parameter will catch all unhandled exceptions – This insures that all exceptions are caught– Of course, it must be the last in the try construct

20The finally Clause

• Optional, at the end of a try-catch-catch construct

• Formfinally {

...

}

• Specifies code that will be always executed, regardless of what happens in the try construct

21Example with finally

• A try construct with a finally clause can be used outside exception handling context

try {for (i = 0; i < 100; i++) { … if (…) {return i;} // index found, return it}

} finally {… // clean up

}

22Continuation

• If no handler is found in the try construct, the search is continued in the nearest enclosing try construct, etc.

• If no handler is found in the method, the exception is propagated to the method’s caller

• If no handler is found (all the way to main), the program is terminated

23Checked and Unchecked Exceptions

• The Java throws clause is different from C++

• Unchecked exceptions– Exceptions of class Error and RunTimeException and their

subclasses

• Checked exceptions– All other exceptions

• A method that may throw a checked exception must– Either handle it, or– List it in the throws clause

• A method cannot declare more exceptions in its throws clause than the method it overrides

24Handling Choices

• An exception can be – Caught and ignored

• Usually a bad, bad choice

– Caught and handled completely– Propagated

• I.e. not caught

– Caught, handled and re-thrown • By throwing it in the handler

– Caught, handled, then a different exception is thrown• Often the best choice as system exceptions carry insufficient

information

25Assertions

• Statements in the program specifying whether the current state of the computation is as expected

• Must form a boolean expression that– When evaluated to true nothing happens

• The program state is ok

– When evaluated to false throws AssertionError

• Can be disabled during runtime without program modification or recompilation

• Two forms– assert condition;– assert condition: expression;

26Evaluation

• The types of exceptions makes more sense than in the case of C++

• The throws clause is better than that of C++ – The throw clause in C++ says little to the programmer

• The finally clause is often useful• The Java interpreter throws a variety of exceptions that

can be handled by user programs