Exception Handling

advertisement

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.

C H A P T E R S I X

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,-,-

SIGLOST -,-,-

A synonym for SIGPWR

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)

6-12

3) everything else

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

6-14

A try needs to catch any exceptions that might occur.

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

6-16

Note that the header of a method is required to declare all the exceptions that it can throw.

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

6-21

Next time…

Object Oriented

Programming

Download