Filter
Top Products
Using Exception Handlers
Using Exception Handlers
Planning the exception handling capability of your application means making the
following decisions:
1. Decide if you will use the RPG-specific means of handling errors (e.g., error
indicator, 'E' extender, or error subroutine) or whether you will write a separate
exception handling routine which you will register using the ILE API CEEHDLR.
You might also choose to use both.
2. Decide on the recovery action, that is, where the program will resume proc-
essing if you use a separate exception handling routine.
In addition, keep in mind the following when planning your exception handlers:
Priority of handlers
Nested exceptions
Default actions for unhandled exceptions
Effect of optimization level
Exception Handler Priority
Exception handler priority becomes important if you use both language-specific
error handling and ILE condition handlers. For an ILE RPG procedure, exception
handlers have the following priority:
1. Either an error indicator or an 'E' extender handler
2. ILE condition handler
| 3. I/O error subroutine handler (for file errors) and Program error subroutine
| handler (for all other errors)
4. RPG default handler for unhandled exceptions (main procedure only)
Nested Exceptions
Exceptions can be nested. A nested exception is an exception that occurs while
another exception is being handled. When this happens, the processing of the first
exception is temporarily suspended. Exception handling begins again with the most
recently generated exception.
Unhandled Exceptions
An unhandled exception is one that has not been handled by an exception handler
associated with the call stack entry that first received the exception. When an
exception is unhandled, one of the following actions occurs:
If the message type is a function check (CPF9999)
associated with a main pro-
cedure
then the RPG default handler will issue an inquiry message describing the
originating condition.
If you pick the D(ump) or C(ancel) option then the procedure which first
received the exception terminates and the function check is percolated to the
caller.
If you pick the R(etry) or G(et Input) option then the function check is handled,
exception processing ends, and the procedure resumes processing at *GETIN
(when G is chosen) or at the I/O operation in which the exception occurred
Chapter 12. Handling Exceptions 223