Wirth and Exceptions

Given Wirth's antipathy to exception mechanisms, I was surprised to read the
following paragraph in his article "The Module [...]" (vide infra). Did he
ever implement such mechanisms in any of his compilers?

john

================================================== ====================
Extract from:

PROCEEDINGS OF THE SYMPOSIUM ON
LANGUAGE DESIGN AND PROGRAMMING METHODOLOGY
SYDNEY, 10-11 SEPTEMBER, 1979

THE MODULE: A SYSTEM STRUCTURING FACILITY IN
HIGH-LEVEL PROGRAMMING LANGUAGES

by Niklaus Wirth



Exception handling

When a programmer is experienced in the use of a structured
language with sufficiently flexible control statements (such as IF,
WHILE, etc.), the GO TO statement will appear as quite dispensable to
him. The introduction of modules, however, in particular of separate modules,
reintroduces the need for a jump. The major need arises from the handling
of exceptional cases, i.e. of exit jumps from procedures. Although this
case might be handled by the passing of additional output parameters,
the exceptional exit jump is desirable, because parameters would cause
additional, unacceptable overhead upon each call. A regular GO TO
statement is inadequate, however, if the point of resumption is unknown
in the module where the exceptional condition arises.

For this purpose, Modula-2 provides a feature called exception.
It is worth emphasizing that the need for it is mainly a consequence
of the module facility. We distinguish between three constructs, called
exception declaration, exception call, and exception handler.
The following example illustrates their use:

MODULE M;
EXCEPTION ex; (* declaration *)

PROCEDURE p;
BEGIN ...
ex (* transfer to Sl, which is invisible here *)
END p;

PROCEDURE q;
BEGIN ... p; ...
WHEN ex DO Sl (* exception handler *)
END q;

BEGIN ... q; ...
ex; (* exception call, handled by S2 *)
WHEN ex DO S2
END M.

When an exception is called, control exits the called procedures
up to the first one which provides a corresponding handler. This
handler is executed, whereupon the procedure is terminated and
execution resumes at the point of its call. The handlers (WHEN ...)
occur at the end of procedure bodies. They can be regarded like
procedures; however, when called, the search follows the dynamic history
of procedure activations instead of the static, nested scopes of
identifier visibility.
================================================== ====================

"john o goyo" <j.o.goyo@adogmail.com> wrote in message
news:fJWdncPhTfla1-LVnZ2dnUVZ_i2dnZ2d@posted.uniservecommunications.. .
> Given Wirth's antipathy to exception mechanisms, I was surprised to read
> the following paragraph in his article "The Module [...]" (vide infra).
> Did he ever implement such mechanisms in any of his compilers?
>

There is an exceptions module included in the PDP-11 version of the Modula-2
compiler which originated from ETH:

DEFINITION MODULE Exceptions; (* Ch. Jacobi 9-Dec-79 *)
(* Unix version 19.05.81 *)

FROM SystemTypes IMPORT ErrorType;

EXPORT QUALIFIED Call, Raise, context, ExeptionPointer;

PROCEDURE Call(p: PROC; VAR res: ErrorType);

(* p: Procedure called.

res: Reason for termination of p.

Producing a PostMortemDump is in the responsibility
of the caller: to propagate the error a call
of Raise(res) is possible.

A small area of the stack is reserved, to
allow the post mortem dump routine not to
destroy the user stack.

Calling Call from other than main process can give
a disaster if later on the main process itself
produces an error. It is possible to change the
context on which exceptions are handled.

Priority is maintained. *)

PROCEDURE Raise(error: ErrorType);
(* Raise (cause) an error;
Raise(propagate) propagates the error
which occured before *)

TYPE ExeptionPointer; (* very hidden ! *)

VAR context: ExeptionPointer;

(* could be used for switching exception
context through a scheduler, don't use
it otherwise *)

END Exceptions.

--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2