This paper is generally disorganized, often vague, and occasionally wrong. Since these are serious condemnations, they are substantiated below.

The paper claims to present a proposal for the design of exception handling facilities in procedural programming languages, with specific emphasis on computational exceptions such as overflow, underflow, zerodivide, etc. Although this subject provides a loose central theme, the paper makes frequent excursions into tangential issues such as variable-precision arithmetic, numerical integration over singularities, and graduate [sic] underflow. None of these subsidiary topics would be out of place in a comprehensive paper on computational exception handling, but the 9-page paper under review makes no pretense of completeness. On the contrary, only the sketchiest outline of the author’s elusive proposal is provided.

That outline appears to contain several confused and incomplete notions. For example, the author regularly refers to “declarations of exception-handlers” and makes the statement:

The scope of the handler is the block in which it is declared, along with any nested sub-blocks . . . unless it is over-ruled by a handler declared in one of those sub-blocks.

In most languages, scope is an attribute that applies to identifiers. Exception handlers are not identifiers; they are procedural code fragments with special entry and exit characteristics. Normally, a specific handler is established by a statement like ON in PL/I or WHEN in ADA; and the conditions which might raise the condition are enabled or disabled in other parts of the program by decorations such as condition prefixes in PL/I or ADA’s SUPPRESS pragma.

It is possible that the author is trying to introduce a new concept that gives exception handlers certain properties, like scope and (re)declarability, which are normally associated with identifiers. Attempting to deduce the author’s intention from the contradictory statements and examples in the paper requires more telepathic ability than this reviewer possesses.

Finally, the paper makes a few statements which are flatly wrong. For example, the author states, “Apparently ADA does not consider underflow to be an exception.” Paragraph 11 of section 11.1 in [1] specifically refers to underflow exceptions in ADA; perhaps the author confused the possibility of underflow exceptions with the fact that ADA offers no T’MACHINE:0U UNDERFLOWS attribute to complement the existence of T’MACHINE:0U OVERFLOWS.