ANS MUMPS defines a number of cases where certain language constructs are either “reserved,” “unspecified,” or “erroneous.” ANS 90 MUMPS does not define what happens when a MUMPS program breaches any of these boundaries. Because a large part of a MUMPS programmer’s task is to produce routines that execute properly, they need and expect some kind of notice when something is wrong. Up to the present, MUMPS implementors have filled this gap with “Z” extensions that report and control the circumstances surrounding an error.

In this article, the term “error processing” refers to the actions that the proposals have the MUMPS language perform; the term “error handling” refers to the MUMPS code supplied by the programmer for invocation during error processing.

Although many of us have written perfect programs on the first try, we’ve all encountered errors because of inadequate or incorrect specifications, mistakes in code written by someone else, cruel and unusual treatment by a user or operator, or even our own occasional slip. Errors in programs are a universal problem. One of the strengths of MUMPS is its pioneering place in the world of open systems. In order to get useful work done in MUMPS, the requirements for constructs beyond the standard are minimal and confined to relatively few areas, namely I/O control (except for database operations), error processing/debugging, and interfaces to the environment outside of MUMPS.

The MDC is actively working in all these areas. It has approved an MDC Type A specification for controlmnemonics and is considering related proposals currently to address the I/O issue. It has approved as MDC Type A the external call and the Structured System Variable (SSVN) specifications, which provide powerful tools for resolving the external interface issues. It is considering the error processing document for elevation to Subcommittee Type A and the naming of errors document for elevation to MDC Type A.

MUMPS users and implementors all have dealt with error processing. Thus we have the experience to cooperate in developing a sound standard error processing mechanism.

Here are the main reasons I’ve heard for not standardizing error processing, and some possible responses:

An initial goal for the error processing proposal was that it be able to emulate all implementation-specific error processing extensions presented to the MDC. The consensus of the task group that has hammered out the proposal is that it comes close. The only exception we are aware of is that DataTree’s DTM-PC and DT-MAX have a mechanism for handling asynchronous errors that permits continuation after handling an error. The current proposals do not provide for continuability, an issue that is discussed in a later section.

Another goal was to minimize the cultural content of error reporting. The MDC is currently investing considerable effort to consider extensions and modifications to MUMPS that permit or assist in making applications easier to “internationalize” or transplant to other parts of the world. In the meantime, we wish to avoid adding anything to the standard that inhibits internationalization (now known to most of the typing-impaired as “i18n”).

MUMPS programs may take several approaches to dealing with an error.

The most brutal approach is to simply terminate the process. This has the virtue of preventing an errant program (and perhaps the person using it) from causing any further damage.

The first approach that comes to the mind of a programmer is to enter direct mode in order to start debugging. Traditionally the MUMPS standard has not addressed the debugging environment (usually referred to as direct or programmer’s mode, or the debugging or MUMPS shell). MUMPS implementations typically provide a shell invoked with the BREAK command or other means. Because in practice almost all language constructs (standard or otherwise) are available in both the normal run-time environment and the debugging shell, it has been convenient for the standard to ignore the details of direct mode.

One concern expressed about the proposal is that some people associate error reporting with the debugging shell and therefore consider it inappropriate for inclusion in the standard. However, a majority in the MDC feels that error reporting should be available to programs as well as programmers and should therefore be standardized. Tradition indicates that features in the standard will be available in direct mode.

Most product managers favor the approach of saving as much context information as possible and then terminating or restarting at a known point. This approach permits the separation in time and place of the error incident and any subsequent debugging attempt.

Eventually, some ambitious user or programmer wants to use the approach of automating the recovery from certain errors. The task group concluded that MUMPS users require the flexibility to invoke some program (maybe as short as a single BREAK or HALT instruction) that handles the error according to goals that vary with the circumstances.

There are many types of error classification to consider. For example, most languages differentiate between compiler errors and run-time errors. (This seems unattractive in a language with the latebinding features of MUMPS that allow arguments and even code to be determined at run-time.) Other popular distinctions are anticipated versus unanticipated, and recoverable versus fatal. Given the discretion that MUMPS typically grants programmers and implementors, the proposals leave both of these classifications to the MUMPS programmer.

Two related types of classification that the task group discussed are continuable versus noncontinuable and restartable versus nonrestartable.

Continuable means that after the error has occurred and error processing has been invoked, the process may be able to resume execution at the next command after the one completed (perhaps unsuccessfully) before error processing. DataTree’s DTM-PC and DT-MAX offer this capability for certain types of errors that are handled asynchronously. Because many of the examples used to argue for continuability seemed to be errors that are asynchronous to the command execution, some task group members proposed that such cases should be treated as events rather than errors. (The MDC has a task group working on event processing.)

A majority of the task group decided that at present it would be unwise either to define in the standard—for every error—whether error handling provides the ability to continue, or to leave that choice entirely to the implementors. In effect, the proposal will require DataTree to introduce an extension for specifically requesting a transfer to the point of continuation.

Restartable means that after the error has occurred and error processing has been invoked, the process may be able to resume execution at the command that caused the error. While the proposal does not provide for restart as a general case, it does permit the error handling program to transfer control at the stack level where the error occurred. This means that if the failing command is preceded on a line only by actions that can safely be repeated (in the simplest case, no actions), the error handler can use a GOTO to cause a restart.

Finally, the proposals implicitly address a classification relating to what MDC members call backwards incompatibility. Where the standard defines errors, the Naming Existing Errors proposal assigns specific error codes. These error codes imply that their associated errors will not be removed from the standard without very serious consideration and ample warning. Where the standard defines reserved or unspecified constructs, the proposals do not assign error codes. While the task group expects that implementors will assign error codes to some or all of these currently unspecified or reserved constructs, the absence of a standard error implies that future standards may enhance the language by using reserved elements or by specifying previously unspecified behavior.

Interestingly enough, this means that while the proposals describe what to do with all errors, including implementor-defined errors, they do not define very much in the way of syntactic errors. This has the additional benefit (at least we hope it is a benefit) of allowing implementors to advance the language by making extensions to MUMPS without having to notify or get permission of the MDC.

The Error Processing proposal specifies that the error transfer happens at the same stack level as the one on which the error is detected. This avoids requiring a new stack level and avoids the problems of managing the case in which the original error is that of exceeding the maximum available stack level. It also preserves the current stack level for examination, debugging, and possible retry. With the chosen approach, a minimalist conversion of existing error processing that automatically changes the stack depth must emulate the stack modification. The later section describing $ESTACK has a simple example of such an emulation.

The error vector is stored in $ETRAP and is in the form of MUMPS code that is to be executed when an error is detected. Error processing inserts this code in the execution stream followed by a QUIT:$QUIT "" QUIT. The purpose of the added code is to QUIT with a null argument if the current stack frame is executing an extrinsic (a condition that causes $QUIT to be TRUE), and otherwise, to QUIT with no argument. This permits easy implementation of the BREAK and HALT cases, as well as emulation of existing error processing that uses a code execution approach. With the proposed approach, a simple conversion method for existing error processing that uses entryref style specifications for vectors is to insert GOTO or DO commands in front of the entryref before assigning them to $ETRAP.

The proposal specifies that an error arising during execution of an error handler is recorded as if it occurred at the stack level above the original error. This is intended to limit the chances of the second error overlaying the information for the first error. After recording the error, MUMPS removes a stack level and attempts error processing at the next lower level. While this does not prevent all possible error-related recursion or looping, it should deal gracefully with those cases of faulty error handling that the task group anticipated as most common. Because they are invoked under abnormal conditions, error handlers need to be carefully constructed and thoroughly tested.

The proposal specifies that error handlers are nested explicitly by issuing a NEW command with $ETRAP as the argument. This permits complete replacement of the current $ETRAP value, not only for the current level but also back as far as the level at which $ETRAP was last NEWed. With the proposed approach, a simple conversion method for existing error processing that implicitly stacks the error vector with every DO, XECUTE or extrinsic is to always NEW $ETRAP before SETting it.

In summary, the proposal chooses a specification for $ETRAP that provides the most flexibility to emulate all the existing error processing approaches brought to the attention of the task group.

This area appears to have more content and perhaps generates more controversy. As you review the features described in this section, remember that many of them are actually required in some form to properly specify the mechanics of the operation of $ETRAP, and also that the task group was attempting to standardize access to what the majority felt were the commonly desired elements of information.

Errors are encoded in comma-delimited strings in $ECODE. All standard errors are numbers registered by the MDC and prefaced with the letter “M.” The reason for using numbers is to minimize the cultural content in the standard. The prefix “Z” is assigned to implementors and the prefix “U” to users. $ECODE is equal to the null string when error processing is not in progress. When $ECODE is not equal to the null string, it should always start with a comma (,) so that the primary error is in the second comma-delimited piece, and so on.

$ECODE can automatically change to a list of one or more codes when MUMPS detects an error, and can also be SET by a program. SET $ECODE="" cancels the error processing “state,” specifically the handling of errors while error processing is active. SET $ECODE="" also cancels the ability to access information about stack levels that have been removed during error processing. However, note that after SET $ECODE="", normal execution will complete the code from $ETRAP and the QUTTs that error processing inserted, unless the programmer takes evasive action with a GOTO. SET $ECODE=var, where var is not null, triggers error processing. Note that var should be of a form such as ",Mn₁,Zn₂,Un₃," (where n₁, n₂ and n₃ are numbers, and only one comma-delimited piece is needed); otherwise, the SET will cause, rather than specify, the recorded error.

The proposals do not provide for standardized error texts. (Remember, we’re trying to be culturally neutral about things the user might see.) However, the task group expects that implementors will provide a mechanism for translating the codes to more user-friendly messages. Once the MDC gets MUMPS internationalized, perhaps it will specify a way to get the error text in the language of your choice.

The $STACK intrinsic special variable returns the current level of nesting of DOs, XECUTEs and extrinsics. The levels counted by $STACK correspond to the PROCESS-STACK model used in the standard as a way of describing transfers of control and their effects on variable management.

The $ESTACK intrinsic special variable counts stack levels as $STACK. However, when $ESTACK is an argument to a NEW command, the effect is to save its current value and give it a value of zero. $ESTACK’s anticipated most common use is controlling which stack level to stop at when emulating existing error processing that automatically removes stack frames. For example:

$ESTACK is somewhat less essential than the rest of the proposal, in that a local variable could replace it in its anticipated most common use.

The $STACK intrinsic function provides access to information that describes the actions that brought the program to the last error, if error processing is active, and otherwise brought the program to the current command. These actions include DO, XECUTE and extrinsic nesting, and also any errors. $STACK() can have one or two arguments. The first argument is evaluated as an integer expression specifying a stack level. If $STACK() has a single argument of -1, it returns the highest level for which the two-argument form will currently return a non-null result. When error processing is not active, $STACK(-1)=$STACK. When error processing is active, $STACK(-1) may be greater than $STACK, indicating that error-trace information is available for stack levels removed in the course of error processing. If $STACK() has a single argument of 0, it returns an implementation-specific value that the task group intends should show something about how MUMPS was invoked. If $STACK() has a single, positive, non-zero argument, it returns either the command word (DO or XECUTE) that invoked the level specified by the argument, or "$$", if the level was invoked by an extrinsic.

The second argument to $STACK() must evaluate to "PLACE" to retrieve the location of the current command at the specified level (as an approximate character offset) in its line (in entryref form) or in its XECUTE string (identified by an "@"). The second argument to $STACK() must evaluate to "MCODE" to retrieve the line, if available, or XECUTE string containing the current command at the specified level. The second argument to $STACK() must evaluate to "ECODE" to retrieve any errors detected at the specified level.

The proposals do not add any features for examining variable context information (including intrinsic special variables or SSVNs). The task group anticipates that many needs for this information can be handled by standard means such as $ORDER() or by implementation-specific extensions such as ZWRITE. The proposals do not provide a standard mechanism, other than removing stack levels, for a program to access variable states that have been NEWed. While as a programmer I can understand the usefulness of such a mechanism in certain debugging situations, I’m not yet convinced that the standard should recognize it as a legitimate programming practice.

The current error processing proposals would provide standard:

These proposals represent a point in a long (about ten years), difficult, and expensive exploration of this problem by much of the MDC, all MUMPS implementors, and many MUMPS power-users.

The people involved in this process are too numerous to properly credit, but I’d like to mention some of the more prominent. If the proposals have elegance, much credit should go to Harlan Stenn, although he might wince at what we did to it after he became occupied with other things. If the proposals are clear, much credit should go to Thomas Salander who has edited the document in many lands and at unspeakable times. If the proposals are usable, much credit should go to Mark Berryman, who has patiently chaired endless meetings and explained problems and solutions to all sides.

Most implementors seem to feel that simply removing the Zs from the elements of their particular error processing facilities would achieve the optimum result. Some users feel the proposals are too complex, while others feel that they are incomplete. It is not yet clear that these proposals have the votes to become part of the standard. Consider whether you need their features, whether you like the proposals, how you might improve them (remember that they need the votes to pass), and mail, phone, e-mail or deliver in person your views to the MDC, or to one or more of its members.