ITECH5403 Comparative Programming Languages

School of Science, Engineering and Information Technology

Lab 4 – Exception Handling and Event Handling

Introduction

Today we'll work on some review questions and exercises relating to exception and event handling.

As usual, I'll remind you that the exam for this course will consist of a selection of questions from each week's lab (80%)
and related questions which help to tie different areas of programming languages together (20%). If you can answer
these questions in the lab – you can answer them in the exam! Remember – in these labs you aren't expected to know
every single answer from memory – sometimes it's best to do a little research / reading / re-reading of materials and come
up with a great, and correct, answer rather than just 'taking a stab' at the question and hoping you're right!

Practical

Work your way through the Oracle Java "Trail" on Exception Handling located at:

http://docs.oracle.com/javase/tutorial/essential/exceptions/index.html

Follow the trail all the way through and complete the Questions and Exercises section (there are only two exercises –
and they're very brief) at the end of the trail.

CRICOS Provider No. 00103D Page 1 of 5

ITECH5403 Comparative Programming Languages

School of Science, Engineering and Information Technology

Review Questions

1. Define events and event handlers. [Q31]

An exception is an event, which occurs during the execution of a program, and that disrupts the normal flow of the
program's instructions

Alternative / simpler phrasing: An event is an action or occurrence detected by a program that may be handled
by the program.

An event handler is a callback subroutine that handles inputs received in a program (called a listener in Java and
JavaScript). An event handler may be registered to listen for specific types of events, and when such an event is detected
the event handler is executed, which may run code to deal with the event appropriately.

Alternative / simpler phrasing: An event handler is a segment of code that is executed in response to the appearance
of an event/ Event handlers allow a program to be responsive to events such as user actions which trigger these
events.

2. What is Event Driven Programming, where/in-what-area would you typically find it used? [Q32]

Event Driven Programming is a programming paradigm in which the flow of the program is determined by events such as
user actions (mouse clicks, key presses), sensor outputs, or messages from other programs/threads which care are
broadcast when the event takes place.

Event-driven programming is the dominant paradigm used in graphical user interfaces and other applications (e.g.
JavaScript web applications) that are centered on performing certain actions in response to user input.

3. What are the advantages of having support for exception handling built into a language? [Q3]

Exceptions provide the means to separate the details of what to do when something out of the ordinary happens from the
main logic of a program. In traditional programming, error detection, reporting, and handling often lead to a confusing
mix of code that performs useful work, and code which handles any issues or error conditions.

A second advantage of exception handling is that errors can be propagated up the call stack so that the error condition
can be handled appropriately for your application. For example, let's say there is a method that reads a file but which
throws an exception if the file does not exist or is malformed – this method can throw an exception if necessary, and your
code calling this method can decide how to handle it – OR – it may opt to "re-throw" the exception up the call stack for
the handling to occur elsewhere, perhaps in a different manner.

Finally, exceptions allow a logical grouping / categorisation of errors which may be handled in different ways. For
example, errors categorised as file IO may be dealt with in one way, while errors categorised as calculation errors (for
example, due to invalid input) may be dealt with in another way.

4. What does it mean for an exception to be bound to an exception handler? [Q5]

For an exception to be bound to an exception handler means that the exception handling method is listening for
exceptions, typically of a specific category or type, and when such an exception occurs it will be sent to the bound
exception handler for it to deal with the error in whatever manner it is programmed to. In Java, a "catch block" can be

CRICOS Provider No. 00103D Page 2 of 5

ITECH5403 Comparative Programming Languages

School of Science, Engineering and Information Technology

considered an exception handler – although the catch block itself doesn't have to be in the same method that the exception
was raised in – instead, the exception may be thrown (perhaps multiple times) until it reaches a catch block which can
handle that particular category of exception.

5. What is the difference between checked and unchecked exceptions in Java? [Q25]

Checked exceptions represent conditions that, although exceptional, can reasonably be expected to occur, and if they do
occur must be dealt with in some way [other than the program terminating]. Checked exceptions represent errors that
unpreventable by us as programmers.

Unchecked exceptions (such as RuntimeExceptions) are due to a programming logic error, they are our fault as
programmers, and are preventable if coded correctly.

6. In what ways are exception handling and event handling related? [30]

Exception handling and event handling both work in an event-driven manner, whereby we do not constantly 'poll' for
events or errors – instead, when they occur they generate a signal which is broadcast and received by an associated
handler to deal with the signal appropriately, whether it's an exception or an event.

Problem Set

1. What did the designers of C get in return for not requiring subscript range checking? [PS1]

The designers of C gained an increase in execution speed for the omission of subscript range checking on arrays, but they
also got a decrease in reliability because the programmer has to be very careful not to go off the end of an array, and if it
happens, then the program may break or crash.

2. Describe three approaches to exception handling in languages that do not provide direct support for it.
[PS2]

Approach 1: Terminate the application and hand control back to the operating system. This is a nice way of saying
"crash"!

Approach 2: Create custom event handling routines and perform your own runtime error checking – if an error is
detected, generate an event which can be used as an exception.

Approach 3: Use encapsulation where accessors and mutators (i.e. getters and setters) contain a lot of sanitisation code
an effort to prevent errors whenever possible. For example, a mutator method for a property that might want to take a
parameter with a value between 1 and 10 but was provided with the value 999 would just cap the value to the legal
maximum of 10 instead of throwing a runtime exception.

3. Write a detailed comparison of the exception-handling capabilities of two languages [PS12-Mod]

CRICOS Provider No. 00103D Page 3 of 5

ITECH5403 Comparative Programming Languages

School of Science, Engineering and Information Technology

Any valid answers for the two chosen languages accepted. Answers should discuss checked/unchecked exceptions,
throw/catch mechanisms, and re-throwing of exceptions if appropriate to the language.

4. Summarise the arguments in favour of the termination and resumption models of continuation [PS14].

You will likely need to read this weeks' reading in order to answer this question:

Gruler, A., & Heinlein, C. (2005). Exception Handling with Resumption: Design and
Implementation in Java. In PLC (pp. 165-171).

Most modern mainstream programming languages include an exception handling mechanism. There are two main types
of exception handling model:
- Mechanisms which support exception termination, and
- Those which support resumption.

Even though resumption was still an attractive alternative to termination for the first exception handling mechanisms in
the 1980s, it has nearly been displaced completely in contemporary languages by termination. However, resumption can
simplify some tasks extremely while still being implementable with reasonable effort.

In termination (which is what C++ supports), you assume the error is so critical that there's no way to automatically
resume execution at the point where the exception occurred. In other words, whoever threw the exception decided there
was no way to salvage the situation, and they don t want to come back.

In the resumption error-handling model, the exception handler is expected to do something to rectify the situation, and
then the faulting code is automatically re-tried, presuming success the second time. If you want resumption in C++, you
must explicitly transfer execution back to the code where the error occurred, usually by repeating the function call that
sent you there in the first place. It is not unusual to place your try block inside a while loop that keeps reentering the try
block until the result is satisfactory.

To quote Wikipedia (http://en.wikipedia.org/wiki/Exception_handling#Termination_semantics):

Exception handling mechanisms in contemporary languages are typically non-resumable ("termination

semantics") as opposed to hardware exceptions, which are typically resumable. This is based on experience
of using both, as there are theoretical and design arguments in favor of either decision; these were
extensively debated during C++ standardization discussions 1989–1991, which resulted in a definitive
decision for termination semantics. On the rationale for such a design for the C++ mechanism, Stroustrup
notes:

[A]t the Palo Alto [C++ standardization] meeting in November 1991, we heard a brilliant summary of the
arguments for termination semantics backed with both personal experience and data from Jim Mitchell
(from Sun, formerly from Xerox PARC). Jim had used exception handling in half a dozen languages over a
period of 20 years and was an early proponent of resumption semantics as one of the main designers and
implementers of Xerox's Cedar/Mesa system. His message was

“termination is preferred over resumption; this is not a matter of opinion but a matter of
years of experience. Resumption is seductive, but not valid.”

He backed this statement with experience from several operating systems. The key example was
Cedar/Mesa: It was written by people who liked and used resumption, but after ten years of use, there was
only one use of resumption left in the half million line system – and that was a context inquiry. Because

CRICOS Provider No. 00103D Page 4 of 5

ITECH5403 Comparative Programming Languages

School of Science, Engineering and Information Technology

resumption wasn't actually necessary for such a context inquiry, they removed it and found a significant
speed increase in that part of the system. In each and every case where resumption had been used it had –
over the ten years – become a problem and a more appropriate design had replaced it. Basically, every use
of resumption had represented a failure to keep separate levels of abstraction disjoint.

So the main difference between termination and resumption semantics is that in resumption semantics the code which
generated the exception is automatically called again once the "resuming" exception handler has run. This presumes the
exception handler can fix the problem – which it may not be able to do, so the exception may be thrown again, and the
program gets stuck in an infinite loop (i.e. in other words, the code will hang).

In termination semantics, we may opt to attempt to perform an operation again, but we are not automatically forced to.

CRICOS Provider No. 00103D Page 5 of 5