[prev] [up] [next]

Exceptions and Signals

This document needs to be updated for class based exceptions. It only describes the old instance based signals. Please read the class-documentation of the Exception class for more info.

Smalltalk provides a powerful and flexible mechanism to handle exceptions and errors in a graceful way. Errors raise a so called Signal, which can be handled by a handlerblock.
Especially with respect to instance creation, deletion and garbage collection, Smalltalk exceptions are very clean and easy to use.
All error conditions can be trapped and reacted upon by signal handlers. This includes situations which are fatal in other languages, such as stack overflow or array index bounds violations.

The most interesting classes are:

Please read ``Exception handling and signals'' for more details.
See ``List of signals'' for a partial list of signals, where they are created and what they mean.

Signal (instance based exceptions)

Notice: this is an old-style (but still supported) mechanism for instance based exception handling. Signals are more lightweight in that they do not need an Exception class to be defined. I.e. you can create and handle such signals dynamically without the overhead of creating a class for it.

Every exception condition is assigned a signal or an exception class, which is raised when that condition is encountered. Therefore, a signal object pr an exception class can be thought of a way to identify a particular exception. Classes which raise a signal (as opposed to an exception) in one of its methods, creates these signal objects at class initialization time and keeps them in class variables for later. These classes provide access methods for these in their class protocol.

Notice that most parts of the system have been changed to use the newer class-based exception mechanism, in which the Exception class itself is used as signal. The protocols and semantics are identical, so all of the following is valid both for signal instances and Exception classes.
Typical use:

More details are found in the Signal and Exception class documentation.


SignalSets represent a collection of Signals that can be handled in one handler as a group. These can be easily created with the , (comma) operator. They understand the same protocol as signals and exception classes: Inside the handlerblock, you can ask for the responsible exception creator by sending creator to the ex argument.

More details are found in the SignalSet class documentation.


ExceptionHandlerSet allows to specify a number of handlers to be specified for a number of signals/exceptions for the execution of the protected block. This avoids the need for deeply nested handler blocks.

They understand the same protocol as signals and exception classes.

Notice the use of ; (cascade) when the above handlerset setup code.

More details are found in the examples section of the ExceptionhandlerSet class documentation.


Instances of Exception are created when a signal/exception is raised. They keep some information on where and why the exception occured and are passed as argument to the signal handler block. Within the handler block, execution can be continued in various ways, via messages to the exception object.
Typical uses:

More details are found in the Exception class documentation.

Copyright 1996 Claus Gittinger Development & Consulting


Doc $Revision: 1.27 $ $Date: 2016/01/21 16:22:39 $