Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
CHAPTER SIX
Exception Handling
Exceptions:
• An exception is a condition that cannot be
resolved within the context of the operation that
caused it. (examples?)
• To throw an exception is to signal that such a
condition has occurred.
• To catch an exception is to transfer control to
an exception handling routine, altering the
normal execution flow of the program.
• Because exceptions are outside the normal
operation of a program the normal, default action
is to write out an error message and terminate
the offending process.
6-2
Exceptions:
Exceptions can occur at many levels:
• Hardware/operating system level.
• Arithmetic exceptions; divide by 0, under/overflow.
• Memory access violations; segfault, stack over/underflow.
• Language level.
• Type conversion; illegal values, improper casts.
• Bounds violations; illegal array indices.
• Bad references; null pointers.
• Program level.
• User defined exceptions.
6-3
Exceptions:
• Older languages did not provide for exception
handling as part of the language definition
(Fortran, COBOL, C).
• Newer languages have added language
constructs to facilitate exception handling (Ada,
C++, Java).
• Depending on the application, handling
exceptions may be a convenience or a necessity.
• Most operating systems provide some sort of
signal mechanism that can be used to provide a
form of exception handling.
6-4
*nix Signal Handling:
• Signals are asynchronous events that can
interrupt the normal execution of a process.
• Some are caused by hardware or software
errors, others can be caused programmatically.
• Signals can be handled in one of three ways:
• Default – do what the O/S thinks is right.
• Ignore – pretend it didn’t happen.
• Signal handler – a user provided function is called.
• The signal system call registers a signal
handling routine that will be executed when a
given signal occurs.
• Not all signals can be caught or ignored
(SIGKILL and SIGSTOP for example).
6-5
*nix Signal Handling:
Linux supports the POSIX.1 signals listed below.
Signal Value Action Comment
-------------------------------------------------------------------------
SIGHUP 1 A Hangup detected on controlling terminal
or death of controlling process
SIGINT 2 A Interrupt from keyboard
SIGQUIT 3 C Quit from keyboard
SIGILL 4 C Illegal Instruction
SIGABRT 6 C Abort signal from abort(3)
SIGFPE 8 C Floating point exception
SIGKILL 9 AEF Kill signal
SIGSEGV 11 C Invalid memory reference
SIGPIPE 13 A Broken pipe: write to pipe with no readers
SIGALRM 14 A Timer signal from alarm(2)
SIGTERM 15 A Termination signal
SIGUSR1 30,10,16 A User-defined signal 1
SIGUSR2 31,12,17 A User-defined signal 2
SIGCHLD 20,17,18 B Child stopped or terminated
SIGCONT 19,18,25 Continue if stopped
SIGSTOP 17,19,23 DEF Stop process
SIGTSTP 18,20,24 D Stop typed at tty
SIGTTIN 21,21,26 D tty input for background process
SIGTTOU 22,22,27 D tty output for background process
6-6
*nix Signal Handling:
Linux supports the extra signals listed below.
Signal Value Action Comment
-------------------------------------------------------------------------
SIGBUS 10,7,10 C Bus error (bad memory access)
SIGPOLL A Pollable event (Sys V). Synonym of SIGIO
SIGPROF 27,27,29 A Profiling timer expired
SIGSYS 12,-,12 C Bad argument to routine (SVID)
SIGTRAP 5 C Trace/breakpoint trap
SIGURG 16,23,21 B Urgent condition on socket (4.2 BSD)
SIGVTALRM 26,26,28 A Virtual alarm clock (4.2 BSD)
SIGXCPU 24,24,30 C CPU time limit exceeded (4.2 BSD)
SIGXFSZ 25,25,31 C File size limit exceeded (4.2 BSD)
SIGIOT 6 C IOT trap. A synonym for SIGABRT
SIGEMT 7,-,7
SIGSTKFLT -,16,- A Stack fault on coprocessor
SIGIO 23,29,22 A I/O now possible (4.2 BSD)
SIGCLD -,-,18 A synonym for SIGCHLD
SIGPWR 29,30,19 A Power failure (System V)
SIGINFO 29,-,- A synonym for SIGPWR
SIGLOST -,-,- A File lock lost
SIGWINCH 28,28,20 B Window resize signal (4.3 BSD, Sun)
SIGUNUSED -,31,- A Unused signal (will be SIGSYS)
6-7
*nix Signal Handling:
The letters in the "Action" column have the following meanings:
A Default action is to terminate the process.
B Default action is to ignore the signal.
C Default action is to terminate the process and dump core.
D Default action is to stop the process.
E Signal cannot be caught.
F Signal cannot be ignored.
6-8
Traditional Techniques:
• Programmers have been dealing with exceptions
for a long time by passing back “special” values
from function or method calls (examples?).
• Sometimes it is hard to distinguish an exception
from normal processing. Consider EOF on read:
• C returns a null value at EOF.
• Ada always throws an exception that the program must
catch.
• Pascal requires an explicit test or the program will
crater!
while not eof(file) do begin
read(file, number);
sum := sum + number;
end;
6-9
Things to consider:
• How is a handler associated with an exception?
• What is the scope of a handler? The whole
program? A single function/method/class or a
block of statements?
• What is the scope of a handler? Do you inherit
from surrounding blocks or previously called
functions?
• What happens if no handler is defined?
• Can execution continue after an exception has
been handled? Some languages allow this (PL/I
and C [mostly]) and some do not (Ada, C++,
Java).
6-10
Exception Handling in Java
Figure 6.1
6-11
Java Exception Type Hierarchy
Figure 6.2
1) virtual machine errors
2)
3) everything else
6-12
Creating a New Exception Class
Figure 6.3
A programmer defined exception is an object of class
Exception or one of its subclasses.
Typical use would be:
if (stack == null) throw new StackUnderflowException();
6-13
Invalid Input Exception
Figure 6.5
A try needs to catch any exceptions that might occur.
6-14
StackUnderflowException Class
Figure 6.6
Most languages allow for application specific
exceptions created by the program and
thrown under the proper circumstances.
6-15
Throwing an Exception
Figure 6.7
Note that the header of a method is required to
declare all the exceptions that it can throw.
6-16
AssertException Class
Figure 6.8
The use of assertion statements is a good way to
help verify the correctness of a program during
debugging. Assertions can be used to check on
arbitrary conditions that the programmer thinks must
be true.
6-17
Assert Class
Figure 6.9
6-18
Using Asserts
Figure 6.10
6-19
Using Asserts:
A runtime exception would occur if a program
tried to do the following:
Stack stack = new Stack();
stack.pop();
To avoid any performance penalties the boolean ON
can be set to false and all asserts protected by
conditionals:
if (Assert.ON) Assert.isTrue( condition );
6-20
Next time…
Object Oriented
Programming
6-21
