c h a p t e r s i x l.
Skip this Video
Loading SlideShow in 5 Seconds..
C H A P T E R S I X PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 21

C H A P T E R S I X - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
c h a p t e r s i x


Exception Handling



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


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.


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

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

*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


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


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


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;



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

Java Exception Type Hierarchy

Figure 6.2

1) virtual machine errors


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


Invalid Input Exception

Figure 6.5

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.


Throwing an Exception

Figure 6.7

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.


Assert Class

Figure 6.9


Using Asserts

Figure 6.10


Using Asserts:

A runtime exception would occur if a program tried to do the following:

Stack stack = new Stack();


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


Next time…

Object Oriented Programming