An exception procedure must be a named, untyped procedure without parameters, and therefore cannot return a value.

An exception procedure cannot contain parameters.

An exception procedure cannot be specified as a formal parameter. However, an exception procedure can be passed as an actual parameter, if the formal parameter is an untyped procedure without parameters.

An invalid GO TO statement cannot be used to exit from the exception procedure to an outer block. A run-time error occurs if an attempt is made to perform an invalid GO TO statement.

An exception procedure cannot contain an EXCEPTION PROCEDURE declaration or an EPILOG PROCEDURE declaration.

An exception procedure cannot be declared as EXTERNAL. Only replacement binding can be used. A block or procedure with an EXCEPTION PROCEDURE declaration in its outer block cannot be bound to. The exception procedure body cannot be a library entry point specification or a dynamic procedure specification.

For other than the outer block of a program, certain string handling declarations, statements, expressions, and functions cause a string pool epilog procedure to be generated for that block to return the string space that was allocated. If a string pool epilog procedure is required for the same block in which an exception procedure is declared, a warning message is generated at compile time because the exception procedure will not be executed at run time for a nonfatal stack overflow fault.

An exception procedure identifier can be included in a library EXPORT list. However, any programs that import this entry point must declare it as a normal, untyped procedure without parameters, not as an exception procedure. The following export is an example:

    EXCEPTION PROCEDURE CLEANUP;
      BEGIN
        % procedure body
      END;  % of exception procedure
    EXPORT
      CLEANUP;