Programming
Languages –
Excep3on Handling and
Event Handling
Jongwoo Lim
Chapter Topics
• Introduc1on to Excep1on Handling
• Excep1on Handling in Ada
• Excep1on Handling in C++
• Excep1on Handling in Java
• Introduc1on to Event Handling
• Event Handling with Java
© 2009 Addison-Wesley.
Introduc3on to Excep3on Handling
• In a language without excep1on handling
-‐ When an excep1on occurs, control goes to the opera1ng system,
where a message is displayed and the program is terminated
• In a language with excep1on handling
-‐ Programs are allowed to trap some excep1ons, thereby providing the
possibility of fixing the problem and con1nuing
© 2009 Addison-Wesley.
Basic Concepts
• Excep1on
-‐ Any unusual event, either erroneous or not, detectable by either
hardware or soGware, that may require special processing
-‐ Excep3on handling: the special processing that may be required
aGer detec1on of an excep1on
-‐ Excep3on handler: the excep1on handling code unit
-‐ An excep1on is raised when its associated event occurs
• Alterna1ves:
-‐ Send an auxiliary parameter or use the return value to indicate the
return status of a subprogram
-‐ Pass a label parameter to all subprograms (error return is to the
passed label)
© 2009 Addison-Wesley.
Excep3on Handling
• Advantages of Built-‐in Excep1on Handling
-‐ Error detec1on code is tedious to write and it cluNers the program
-‐ Excep1on handling encourages programmers to consider many
different possible errors
-‐ Excep1on propaga1on allows a high level of reuse of excep1on
handling code
© 2009 Addison-Wesley.
Design Issues
• How and where are excep1on handlers specified and what is
their scope?
• How is an excep1on occurrence bound to an excep1on handler?
• Can informa1on about the excep1on be passed to the handler?
• Where does execu1on con1nue, if at all, aGer an excep1on
handler completes its execu1on? (con1nua1on vs. resump1on)
• Is some form of finaliza1on provided?
© 2009 Addison-Wesley.
Design Issues
• How are user-‐defined excep1ons specified?
• Should there be default excep1on handlers for programs that do
not provide their own?
• Can built-‐in excep1ons be explicitly raised?
• Are hardware-‐detectable errors treated as excep1ons that can be
handled?
• Are there any built-‐in excep1ons?
• How can excep1ons be disabled, if at all?
© 2009 Addison-Wesley.
Excep3on Handling Control Flow
© 2009 Addison-Wesley.
Excep3on Handling in Ada
• The frame of an excep1on handler in Ada is either a subprogram
body, a package body, a task, or a block
-‐ Because excep1on handlers are usually local to the code in which the
excep1on can be raised, they do not have parameters
-‐ Handlers are placed at the end of the block or unit in which they
occur
• Excep1on handler form:
when exception_choice{|exception_choice} => stmt_sequence
exception_choice := exception_name | others
© 2009 Addison-Wesley.
Binding Excep3ons to Handlers
• The excep1on is propagated
-‐ If the block or unit in which an excep1on is raised does not have a
handler for that excep1on
-‐ Procedures: propagate it to the caller
-‐ Blocks: propagate it to the scope in which it appears
-‐ Package body: propagate it to the declara1on part of the unit that
declared the package (if it is a library unit, the program is
terminated)
-‐ Task: no propaga1on; if it has a handler, execute it; in either case,
mark it "completed"
© 2009 Addison-Wesley.
Excep3on Handling in Ada
• Con1nua1on
-‐ The block or unit that raises an excep1on but does not handle it is
always terminated (also any block or unit to which it is propagated
that does not handle it)
• User-‐defined Excep1ons form:
exception_name_list : exception;
• Raising Excep1ons form:
raise [exception_name]
-‐ The excep1on name is not required if it is in a handler
• Excep1on condi1ons can be disabled with:
pragma SUPPRESS(exception_list) © 2009 Addison-Wesley.
Predefined Excep3ons
• CONSTRAINT_ERROR -‐ index constraints, range constraints,
etc.
• NUMERIC_ERROR -‐ numeric opera1on cannot return a correct
value (overflow, division by zero, etc.)
• PROGRAM_ERROR -‐ call to a subprogram whose body has not
been elaborated
• STORAGE_ERROR -‐ system runs out of heap
• TASKING_ERROR -‐ an error associated with tasks
© 2009 Addison-Wesley.
Evalua3on
• The Ada design for excep1on handling embodies the state-‐of-‐the-‐
art in language design in 1980
• Ada was the only widely used language with excep1on handling
un1l it was added to C++
© 2009 Addison-Wesley.
Excep3on Handling in C++
• Added to C++ in 1990
• Design is based on that of CLU, Ada, and ML
© 2009 Addison-Wesley.
C++ Excep3on Handlers
• Excep1on Handlers Form:
try {
// code that is expected to raise an exception
}
catch (formal parameter) {
// handler code
}
...
catch (formal parameter) {
// handler code
}
© 2009 Addison-Wesley.
The catch Func3on
• catch is the name of all handlers
-‐ Formal parameter of each must be unique
-‐ The formal parameter need not have a variable
• Simply a type name to dis1nguish the handler from others
-‐ The formal parameter can be used to transfer informa1on to the
handler
-‐ The formal parameter can be an ellipsis (...), in which case it handles
all excep1ons not yet handled
• Unhandled excep1on
-‐ Propagated to the caller of the func1on in which it is raised
-‐ This propaga1on con1nues to the main func1on
-‐ If no handler is found, the default handler is called
© 2009 Addison-Wesley.
Throwing Excep3ons
• Excep1ons are all raised explicitly by the statement:
throw [expression];
-‐ The brackets are metasymbols
-‐ A throw without an operand can only appear in a handler; when it
appears, it simply re-‐raises the excep1on, which is then handled
elsewhere
-‐ The type of the expression disambiguates the intended handler
• Con1nua1on
-‐ AGer a handler completes its execu1on, control flows to the first
statement aGer the last handler in the sequence of handlers of which
it is an element
© 2009 Addison-Wesley.
C++ Excep3on Handlers
• Other design choices
-‐ All excep1ons are user-‐defined
-‐ Excep1ons are neither specified nor declared
-‐ The default handler, unexpected, simply terminates the program;
unexpected can be redefined by the user
-‐ Func1ons can list the excep1ons they may raise
-‐ Without a specifica1on, a func1on can raise any excep1on (the
throw clause)
© 2009 Addison-Wesley.
Evalua3on
• It is odd that excep1ons are not named and that hardware-‐ and
system soGware-‐detectable excep1ons cannot be handled
• Binding excep1ons to handlers through the type of the
parameter certainly does not promote readability
© 2009 Addison-Wesley.
Excep3on Handling in Java
• Based on that of C++, but more in line with OOP philosophy
• All excep1ons are objects of classes that are descendants of the
Throwable class
© 2009 Addison-Wesley.
Classes of Excep3ons
• Java includes two subclasses of Throwable :
- Error
• Thrown by the Java interpreter for events such as heap overflow
• Never handled by user programs
- Exception
• User-‐defined excep1ons are usually subclasses of this
• Has two predefined subclasses, IOException and
RuntimeException (e.g.,
ArrayIndexOutOfBoundsException and
NullPointerException)
© 2009 Addison-Wesley.
Java Excep3on Handlers
• Like those of C++, except every catch requires a named
parameter and all parameters must be descendants of
Throwable
• Syntax of try clause is exactly that of C++
• Excep1ons are thrown with throw, as in C++, but oGen the
throw includes the new operator to create the object, as in:
throw new MyException();
© 2009 Addison-Wesley.
Binding Excep3ons to Handlers
• Binding an excep1on to a handler is simpler in Java than it is in C+
+
-‐ An excep1on is bound to the first handler with a parameter is the
same class as the thrown object or an ancestor of it
• An excep1on can be handled and rethrown by including a throw
in the handler (a handler could also throw a different excep1on)
© 2009 Addison-Wesley.
Con3nua3on
• If no handler is found in the try construct, the search is
con1nued in the nearest enclosing try construct, etc.
• If no handler is found in the method, the excep1on is propagated
to the method’s caller
• If no handler is found (all the way to main), the program is
terminated
• To insure that all excep1ons are caught, a handler can be
included in any try construct that catches all excep1ons
-‐ Simply use an Exception class parameter
-‐ Of course, it must be the last in the try construct
© 2009 Addison-Wesley.
Checked and Unchecked Excep3ons
• The Java throws clause is quite different from the throw
clause of C++
• Unchecked excep1ons: excep1ons of class Error and
RunTimeException and all of their descendants
• Checked excep1ons: all other excep1ons
-‐ Thrown by a method must be either:
• Listed in the throws clause, or
• Handled in the method
© 2009 Addison-Wesley.
Other Design Choices
• A method cannot declare more excep1ons in its throws clause
than the method it overrides
• A method that calls a method with throws clause has three
alterna1ves for dealing with that excep1on:
-‐ Catch and handle the excep1on
-‐ Catch the excep1on and throw an excep1on that is listed in its own
throws clause
-‐ Declare it in its throws clause and do not handle it
© 2009 Addison-Wesley.
The finally Clause
• Can appear at the end of a try construct
finally {
...
}
-‐ Specify code that is to be executed, regardless of what happens in
the try construct
© 2009 Addison-Wesley.
Example
• A try construct with a finally clause can be used outside
excep1on handling
try {
for (index = 0; index < 100; index++) {
...
if (...) {
return;
} //** end of if
} //** end of for
} //** end of try clause
finally {
...
} //** end of try construct
© 2009 Addison-Wesley.
Asser3ons
• Declare a boolean expression regarding the current state of the
computa1on
-‐ When evaluated to true nothing happens
-‐ When evaluated to false an AssertionError excep1on is thrown
-‐ Can be disabled during run1me without program modifica1on or
recompila1on
• Two forms
-‐ assert condi1on;
-‐ assert condi1on: expression;
© 2009 Addison-Wesley.
Evalua3on
• The types of excep1ons makes more sense than in the case of C+
+
• The throws clause is beNer than that of C++ (The throw clause
in C++ says liNle to the programmer)
• The finally clause is oGen useful
• The Java interpreter throws a variety of excep1ons that can be
handled by user programs
© 2009 Addison-Wesley.
Introduc3on to Event Handling
• An event is created by an external ac1on such as a user
interac1on through a GUI
• The event handler is a segment of code that is called in response
to an event
© 2009 Addison-Wesley.
Java Swing GUI Components
• Text box is an object of class JTextField
• Radio buNon is an object of class JRadioButton
• Applet’s display is a frame, a mul1layered structure
• Content pane is one layer, where applets put output
• GUI components can be placed in a frame
• Layout manager objects are used to control the placement of
components
© 2009 Addison-Wesley.
The Java Event Model
• User interac1ons with GUI components create events that can be
caught by event handlers, called event listeners
• An event generator tells a listener of an event by sending a
message
• An interface is used to make event-‐handling methods conform to
a standard protocol
• A class that implements a listener must implement an interface
for the listener
© 2009 Addison-Wesley.
The Java Event Model
• One class of events is ItemEvent, which is associated with the
event of clicking a checkbox, a radio buNon, or a list item
• The ItemListener interface prescribes a method,
itemStateChanged, which is a handler for ItemEvent
events
• The listener is created with addItemListener
© 2009 Addison-Wesley.
Summary
• Ada provides extensive excep1on-‐handling facili1es with a
comprehensive set of built-‐in excep1ons.
• C++ includes no predefined excep1ons Excep1ons are bound to
handlers by connec1ng the type of expression in the throw
statement to that of the formal parameter of the catch
func1on
• Java excep1ons are similar to C++ excep1ons except that a Java
excep1on must be a descendant of the Throwable class.
Addi1onally Java includes a finally clause
• An event is a no1fica1on that something has occurred that
requires handling by an event handler
© 2009 Addison-Wesley.
