Transcript CSP 506 Comparative Programming Languages

CPS 506
Comparative Programming
Languages
Exception Handling
Topics
• Introduction to Exception
Handling
• Exception Handling in Ada
• Exception Handling in C++
• Exception Handling in Java
• Introduction to Event Handling
• Event Handling with Java
2
Introduction to Exception Handling
• In a language without exception handling
– When an exception occurs
• Control goes to the operating system
• A message is displayed
• The program is terminated
• In a language with exception handling
– Programs are allowed to
• Trap some exceptions
• Providing the possibility of fixing the problem
• Continuing the program
3
Basic Concepts
• Many languages allow programs to trap input/output errors
(including EOF)
• An exception is
– Any unusual event
• erroneous or not
• Detectable by either hardware or software
• May require special processing
• The special processing that may be required after
detection of an exception is called
– Exception Handling
• The exception handling code unit is called an
– Exception Handler
4
Exception Handling Alternatives
•
An exception is raised when its associated event occurs
•
A language that does not have exception handling capabilities can still
– Define
– Detect
– Raise
– Handle
exceptions (user defined, software detected)
•
Alternatives:
– 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 returns into the
passed label)
– Pass an exception handling subprogram to all subprograms
5
Advantages of Built-in Exception
Handling
• Error detection code
– Is tedious to write
– It clutters the program
• Exception handling
– Encourages programmers to consider many
different possible errors
• Exception propagation
– Allows a high level of reuse of exception
handling code
6
Design Issues
• How and where are exception handlers specified?
• What is their scope?
• How is an exception occurrence bound to an
exception handler?
• Can information about the exception be passed to
the handler?
• Where does execution continue, if at all, after an
exception handler completes its execution?
(continuation vs. resumption)
• Is some form of finalization provided?
7
Design Issues (con’t)
• How are user-defined exceptions specified?
• Should there be default exception handlers
for programs that do not provide their own?
• Can built-in exceptions be explicitly raised?
• Are hardware-detectable errors treated as
exceptions that can be handled?
• Are there any built-in exceptions?
• How can exceptions be disabled, if at all?
8
Exception Handling Control Flow
9
Exception Handling in Ada
• The frame of an exception handler in
Ada is either
– A subprogram body
– A package body
– A task
– Or a block
• No parameter
– Because exception handlers are usually local
to the code in which the exception can be
raised, they do not have parameters
10
Ada Exception Handlers
• Handler form:
when exception_choice{|exception_choice} =>
statement_sequence
...
[when others =>
statement_sequence]
exception_choice form:
exception_name | others
• Handlers are placed at the end of the block or
unit in which they occur
11
Binding Exceptions to Handlers
• If the block or unit in which an exception is raised does not
have a handler for that exception, the exception is
propagated elsewhere to be handled
– Procedures - propagate it to the caller
– Blocks - propagate it to the scope in which it appears
– Package body - propagate it to the declaration part of
the unit that declared the package
• If it is a library unit, which is separately compiled, the
program is terminated
– Task - no propagation
• If it has a handler, execute it
• In either case, mark it "completed"
12
Continuation
• The block or unit that raises an
exception, along with all units to which
the exception was propagated but did not
handle it is always terminated
• Also any block or unit to which it is
propagated that does not handle it, is
terminated
• Return to a higher level of control
13
Other Design Choices
• Each predefined package has some exceptions
• User-defined Exceptions form:
exception_name_list : exception;
– Should be raised explicitly
– Raising Exceptions form:
raise [exception_name]
– The exception name is not required if it is in a
handler--in this case, it propagates the same
exception
• Exception conditions can be disabled with:
pragma Suppress(exception_list)
14
Predefined Exceptions
• CONSTRAINT_ERROR - index constraints, range
constraints, etc.
• NUMERIC_ERROR - numeric operation cannot
return a correct value (overflow, division by zero,
etc.)
• PROGRAM_ERROR - call to a subprogram whose
body has not been implemented
• STORAGE_ERROR - system runs out of heap
• TASKING_ERROR - an error associated with
tasks
15
Evaluation
• The Ada design for exception handling
embodies the state-of-the-art in
language design in 1980
• Ada was the only widely used language
with exception handling until it was added
to C++
16
Exception Handling in C++
• Added to C++ in 1990
• Design is based on that of CLU, Ada, and
ML
17
C++ Exception Handlers
• Exception Handlers Form:
try {
-- code that is expected to raise an exception
}
catch (formal parameter) {
-- handler code
}
...
catch (formal parameter) {
-- handler code
}
18
The catch Function
• catch is the name of all handlers--it is an
overloaded name, so the formal parameter of
each must be unique
• The formal parameter need not have a variable
– It can be simply a type name to distinguish the
handler it is in from others
• The formal parameter can be used to transfer
information to the handler
• The formal parameter can be an ellipsis, in which
case it handles all exceptions not yet handled
19
Throwing Exceptions
• Exceptions are all raised explicitly by the
statement:
throw [expression];
• The brackets are metasymbols, i.e. expression is
optional
• A throw without an operand can only appear in a
handler; when it appears, it simply re-raises the
exception
• The type of the expression disambiguates the
intended handler
20
Unhandled Exceptions
• An unhandled exception is propagated to
the caller of the function in which it is
raised
• This propagation continues to the main
function
• If no handler is found, the default
handler is called
21
Continuation
• After a handler completes its execution,
control flows to the first statement
following the try construct
• Other design choices
– All exceptions are user-defined
– The default handler, unexpected,
simply terminates the program
22
Exception Handling in Java
• Based on that of C++, but more in line
with OOP philosophy
• All exceptions are objects of classes that
are descendants of the Throwable class
23
Classes of Exceptions
• The Java library includes two subclasses of Throwable :
– Error
• Is thrown by the Java interpreter for events such
as heap overflow
• Is never handled by user programs
– Exception
• User-defined exceptions are usually subclasses of
this
• Has two predefined subclasses
– IOException
– RuntimeException
– Examples
» ArrayIndexOutOfBoundsException
» NullPointerException
24
Java Exception 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++
• Exceptions are thrown with throw, as in C++,
but often the throw includes the new
operator to create the object, as in:
throw new MyException();
25
Binding Exceptions to Handlers
• Binding an exception to a handler is simpler
in Java than it is in C++
– An exception is bound to the first
handler with a parameter is the same
class as the thrown object or an ancestor
of it
• An exception can be handled and rethrown
by including a throw in the handler (a
handler could also throw a different
exception)
26
Continuation
• 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
• To insure that all exceptions are caught, a handler can be
included in any try construct that catches all exceptions
– Simply use an Exception class parameter
– Of course, it must be the last in the try construct
27
Checked and Unchecked Exceptions
• The Java throws clause is quite different from
the throw clause of C++
• Exceptions of class Error and RunTimeException
and all of their descendants are called unchecked
exceptions; all other exceptions are called
checked exceptions
• Checked exceptions that may be thrown by a
method must be either:
– Listed in the throws clause, or
– Handled in the method
28
Other Design Choices
• A method cannot declare more
exceptions in its throws clause than the
method it overrides
• No default exception handler
• No possibility to disable exceptions
• Continuation is the same as that in C++
29
The finally Clause
• Can appear at the end of a try construct
• Form:
finally {
...
}
• Purpose: To specify code that is to be
executed, regardless of what happens in
the try construct
30
Example
• A try construct with a finally clause can be used
outside exception handling
try {
for (index = 0; index < 100; index++) {
…
if (…) {
return;
} //** end of if
} //** end of try clause
finally {
…
} //** end of try construct
31
Assertions
• Statements in the program declaring a boolean expression
regarding the current state of the computation
• When evaluated to true nothing happens
• When evaluated to false an AssertionError exception is
thrown
• Two forms
assert condition;
assert condition: expression;
• Used for program correctness testing
• Can be disabled during runtime without program
modification or recompilation
32
Evaluation
• 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
33