Editing PL/I (section)

===ON-units and exception handling===
When PL/I was designed, programs only ran in batch mode, with no possible intervention from the programmer at a terminal. An exceptional condition such as division by zero would abort the program yielding only a hexadecimal core dump. PL/I exception handling, via {{tt|ON}}-units, allowed the program to stay in control in the face of hardware or operating system exceptions and to recover debugging information before closing down more gracefully. As a program became properly debugged, most of the exception handling could be removed or disabled: this level of control became less important when conversational execution became commonplace.

Computational exception handling is enabled and disabled by condition prefixes on statements, blocks (including {{tt|ON}}-units) and procedures. – e.g., <code>(SIZE, NOSUBSCRIPTRANGE): A(I)=B(I)*C; </code>. Operating system exceptions for Input/Output and storage management are always enabled.

The {{tt|ON}}-unit is a single statement or {{tt|BEGIN}}-block introduced by an {{tt|ON}}-statement. Executing the {{tt|ON}} statement enables the condition specified, e.g., <code>ON ZERODIVIDE ON</code>-unit. When the exception for this condition occurs and the condition is enabled, the {{tt|ON}}-unit for the condition is executed. {{tt|ON}}-units are inherited down the call chain. When a block, procedure or {{tt|ON}}-unit is activated, the {{tt|ON}}-units established by the invoking activation are inherited by the new activation. They may be over-ridden by another {{tt|ON}}-statement and can be reestablished by the {{tt|REVERT}}-statement. The exception can be simulated using the {{tt|SIGNAL}}-statement – e.g., to help debug the exception handlers. The dynamic inheritance principle for {{tt|ON}}-units allows a routine to handle the exceptions occurring within the subroutines it uses.

If no {{tt|ON}}-unit is in effect when a condition is raised a standard system action is taken (often this is to raise the {{tt|ERROR}} condition). The system action can be reestablished using the {{tt|SYSTEM}} option of the {{tt|ON}}-statement. With some conditions it is possible to complete executing an ON-unit and return to the point of interrupt (e.g., the {{tt|STRINGRANGE}}, {{tt|UNDERFLOW}}, {{tt|CONVERSION}}, {{tt|OVERFLOW}}, {{tt|AREA}}, and {{tt|FILE}} conditions) and resume normal execution. With other conditions such as <code>(SUBSCRIPTRANGE)</code>, the {{tt|ERROR}} condition is raised when this is attempted. An ON-unit may be terminated with a <code>GO TO</code> preventing a return to the point of interrupt, but permitting the program to continue execution elsewhere as determined by the programmer.

An {{tt|ON}}-unit needs to be designed to deal with exceptions that occur in the {{tt|ON}}-unit itself. The <code>ON ERROR SYSTEM;</code> statement allows a nested error trap; if an error occurs within an {{tt|ON}}-unit, control might pass to the operating system where a system dump might be produced, or, for some computational conditions, continue execution (as mentioned above).

The PL/I {{tt|RECORD}} I/O statements have relatively simple syntax as they do not offer options for the many situations from end-of-file to record transmission errors that can occur when a record is read or written. Instead, these complexities are handled in the {{tt|ON}}-units for the various file conditions. The same approach was adopted for {{tt|AREA}} sub-allocation and the {{tt|AREA}} condition.

The existence of exception handling {{tt|ON}}-units can have an effect on optimization, because variables can be inspected or altered in {{tt|ON}}-units. Values of variables that might otherwise be kept in registers between statements, may need to be returned to storage between statements. This is discussed in the section on Implementation Issues above.<ref name=IBMLR43 />{{rp|pp.249–376}}