Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site plus5.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!plus5!herring%nimbus.DEC From: herring%nimbus.DEC@plus5.UUCP Newsgroups: mod.std.mumps Subject: Error and exception handling Message-ID: <906@plus5.UUCP> Date: Wed, 23-Oct-85 23:24:20 EDT Article-I.D.: plus5.906 Posted: Wed Oct 23 23:24:20 1985 Date-Received: Fri, 25-Oct-85 03:53:57 EDT Sender: hokey@plus5.UUCP Reply-To: nimbus.DEC!herring Organization: Plus Five Computer Services, St. Louis Lines: 123 Approved: hokey@plus5.uucp Volume-Issue: 2.7 Page 1 of 2 Proposal to the Mumps Development Committee by Barry Herring, Digital Equipment Corporation Subject: Error and exception handling Overview: Although certain conditions are described by the Mumps standard as "erroneous", no mechanism is specified to implementors for handling those conditions, nor is any recovery mechanism specified for MUMPS applications. In addition to "errors", there is a class of conditions associated with I/O commands that can be termed "exceptions", where the Mumps programmer does not want routine execution to continue normally, but the condition is not unexpected or erroneous. These exception conditions are generally implementor defined, whereas error conditions are specified by the standard. For both types of conditions, there are two areas where the standard is wanting. First, there is no standard way of reporting error inform- ation. Secondly, there is no standard way of allowing an application to recover and continue a job that encounters an error. The following proposal adds to the MUMPS standard a mechanism for both reporting and recovering from error and exception condition. For the purposes of this proposal, errors and exception conditions will both be referred to as errors. The proposal specifies the mechanism, a new command for declaring an error handling routine, and special variables for passing error information from the system to application routines. The scheme includes provision for allowing called routines to process error or exception conditions transparently to the caller. At section 1.2.6 add the following lines to the command summary: ETRAP declares an error processing routine. EQUIT invokes a continuation of error processing. At section 1.2.8 add the following lines to the special variable summary: $ERROR provides information about the last error. $ETRAP holds the last value specified by the ET commmand. At section 3.2.7 add the following paragraphs: $ER[ROR] $ER holds information about the last error condition encountered by the job. The information deposited in $ER is implementor defined. See section 3.5.10. $ET[RAP] $ET holds the last entryref specified by an ET command. $ET may also contain the empty string. See section 3.5.10. page 2 of 2 Add a new section to describe error processing: 3.5.10 Error handling Error trapping provides a mechanism by which a MUMPS job can execute a specifiable routine or routine fragment in the event that the system encounters an error or implementor-defined exception condition. The following MUMPS facilities are provided for use by the MUMPS programmer: The ET command takes an entryref argument as the specification of an error processing subroutine. The value specified by ET is placed in the $ET special variable. Upon execution of a DO or XECUTE command, the $ET special variable is stacked, and the current contents of $ET is replaced by the empty string. The ER special variable provides implementor-defined information about the last error encountered by the job. Each MUMPS implementation must perform the following interpreter actions upon detection of an error or exception condition: 1. Replace the previous contents of the $ER special variable with information about the new error. 2. If the $ET special variable does not contain the empty string, go to step 4. 3. Else restore the previous routine from the stack, including 'NEW' frames, parameter frames, and the previous value of $ET. Repeat step 2 above. 4. Control is transferred to the entryref specified by $ET. This action is equivalent to the execution of "GOTO @$ET" at the point of the error or exception condition. Execution resumes at the new line. Note that the variable environment at this point is the same as that when this $ET value was set. Insert the following command descriptions in section 3.6: 3.6.x ETRAP ET[RAP] postcond | [ ] | | entryref | ETRAP sets the $ETRAP special variable, used by error trapping. In its argumentless form, ETRAP sets $ETRAP to the empty string. See section 3.5.10. 3.6.y EQUIT EQ[UIT] postcond [ ] EQUIT replaces the current contents of the $ETRAP special variable with the empty string, then invokes error processing but without changing the $ERROR special variable. This is equivalent to entering at step 3 of the algorithm specified in section 3.5.10. EQUIT is used to "pop back" to a lower (older) level of execution.