C H A P T E R S I X

1. C H A P T E R S I X Exception Handling

2. 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.

3. 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.

4. 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.

5. *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. *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

7. *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)

8. *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.

9. 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;

10. 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).

11. Exception Handling in Java Figure 6.1

12. Java Exception Type Hierarchy Figure 6.2 1) virtual machine errors 2) 3) everything else

13. 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();

14. Invalid Input Exception Figure 6.5 A try needs to catch any exceptions that might occur.

15. StackUnderflowException Class Figure 6.6 Most languages allow for application specific exceptions created by the program and thrown under the proper circumstances.

16. Throwing an Exception Figure 6.7 Note that the header of a method is required to declare all the exceptions that it can throw.

17. 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.

18. Assert Class Figure 6.9

19. Using Asserts Figure 6.10

20. 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 );

21. Next time… Object Oriented Programming