Exception Handling

The special processing that may be required when an exception is detected is called exception handling. This processing is done by a code unit or segment called an exception handler. An exception is raised when its associated event occurs. In programming language that supports exception handling, programs are allowed to trap some exceptions, thereby providing the possibility of fixing the problem and continuing. In programming languages that doesn’t support exception handling, when an exception occurs, control goes to the operating system, where a message is displayed and the program is terminated.

The absence of separate or specific exception-handling facilities in a language does not preclude the handling of user-defined, software-detected exceptions. Such an exception detected within a program unit is often handled by the unit’s caller, or invoker. One possible design is to send an auxiliary parameter, which is used as a status variable. Another possibility is to pass a label parameter to the subprogram. A third possibility is to have the handler defined as a separate subprogram whose name is passed as a parameter to the called unit.

There are some definite advantages to having exception handling built into a language. First, without exception handling, the code required to detect error conditions can considerably clutter a program. Another advantage of language support for exception handling results from exception propagation. Exception propagation allows an exception raised in one program unit to be handled in some other unit in its dynamic or static ancestry.

A language that supports exception handling encourages its users to consider all of the events that could occur during program execution and how they can be handled. This approach is far better than not considering such possibilities and simply hoping nothing will go wrong. This advantage is related to requiring a multiple-selector construct to include actions for all possible values of the control expression.

The first design issue for exception handling is how an exception occurrence is bound to an exception handler. This issue occurs on two different levels. On the unit level, there is the question of how the same exception being raised at different points in a unit can be bound to different handlers within the unit. At a higher level, the binding question arises when there is no exception handler local to the unit in which the exception is raised.

Catch, Try, and Throw

A try construct includes a compound statement called the try clause and a list of exception handlers. The compound statement defines the scope of the following handlers. A catch function can have only a single formal parameter, which is similar to a formal parameter in a function definition. A throw without an operand can appear only in a handler. When it appears there, it raises the exception, which is then handled elsewhere. The type of the throw expression selects the particular handler, which of course must have a “matching” type formal parameter.

Event Handling

Event handling is similar to exception handling. In both cases, the handlers are implicitly called by the occurrence of something, either an exception or an event. While exceptions can be created either explicitly by user code or implicitly by hardware or a software interpreter, events are created by external actions, such as user interactions through a graphical user interface (GUI).

An event is a notification that something specific has occurred, such as a mouse click on a graphical button. Strictly speaking, an event is an object that is implicitly created by the run-time system in response to a user action, at least in the context in which event handling is being discussed here.

An event handler is a segment of code that is executed in response to the appearance of an event. Event handlers enable a program to be responsive to user actions. Although event-driven programming was being used long before GUIs appeared, it has become a widely used programming methodology only in response to the popularity of these interfaces.