IBM i General Design Standards › Design Standards for Programs › Error Handling

Error Handling

Good error handling design should serve to contain the damage from errors. Errors should be brought to the operator’s attention, but the system should retain its integrity, and, if possible, continue.

In general, you should aim for defense in depth. Assume things will go wrong at every level.

The default error handling features of OS/400 provide an excellent framework for error handling, and can be used as the norm. The only design decision required is as to when, if ever, you should override the handling with your own processing.

Errors fall into three general classes:

• Application generated (for example, "record not found"), since you create the messages you are handling them by definition.
• System generated, because of pathological errors (for example, decimal data errors, errors due to missing programs or files). Do not attempt to handle pathological errors. Let the message handling capabilities of OS/400 force a request for the operator’s attention.
• System generated because of routine errors (for instance, due to record locks). You will probably want to handle such errors explicitly so that automatic recovery can take place and processing can continue.

One of the main differences between the design requirements of batch and interactive programs lies in the error handling.

For interactive programs, error handling is relatively straightforward. An error message can be issued, suggesting one or more options, and the program can wait for immediate guidance. Where a partial update has taken place, it is possible to indicate what has and what has not been implemented.

For batch programs, error handling is more complicated. You must allow for errors of varying levels of severity, ranging from terminal errors, which require immediate and complete abortion of the process, to warning errors, which require the program to take default action in order to be able to continue unattended. In any case, the operator needs to be alerted as to the potential problems. You should also consider whether, if a fatal error occurs, subsequent jobs should be allowed to continue.

OS/400 error handling imposes a certain overhead. You should code so that exception handling is invoked on the least used path. For example, say that you are adding/updating records on a file. If the record will not normally already exist on file, you should attempt to add the record, and monitor for an exception, in which case, you will chain and update the record, rather than vice versa.