The Basics of Error-Message Handling

All Forms errors belong to a standard type of FRM and are characterized by

• Error type ” Whether the error is an informative message or an actual error message
• Error code ” An integer indicating the error number
• Error text ” The text of the error message
• Error severity level ” The classification of the error message

Error Type

An informative -type error message results from an error caused by some missing data or insufficient data and is not an error in the strict sense. No action is necessary by default, and further processing can be resumed after the occurrence of the error.

Examples are

FRM-40350: Query caused no records to be retrieved. FRM-40353: Query Cancelled.

However, these types of errors can be tracked and replaced by customized messages to improve readability to the end user .

An error -type error message results from an error in the strict sense, which must be rectified before further processing can resume.

Examples are

FRM-40202: Field must be entered. FRM-40360: Cannot Query Records here. FRM-40600: Record has already been inserted.

In Forms, few error-type error messages occur for which no action is required. A commonly occurring example is

FRM-40100: At first record.

When the cursor is in the first record in a block and the user presses the or key, this error is raised and requires no action to be taken. However, the same error resulting from the built-in FIRST_RECORD is a genuine failure, and the code following this built-in is executed after the FRM-40100 error message is displayed. The latter error might result when the user presses the Enter key and the corresponding KEY-NEXT-ITEM trigger has a call to FIRST_RECORD in it:

KEY-NEXT-ITEMFIRST_RECORD; ---

In this case, if the cursor is in the first record in the block, the code following the FIRST_RECORD built-in is executed after the error message FRM-40100 is displayed.

The only way to distinguish between an informative error message and an actual error message is by further processing, usually at runtime, without correcting the error. (Of course, the easy way is to look at the online help.)

Tip

Failure of built-ins or form object properties can be the cause of both informative-type and error-type error messages.

Error Severity Level

Most error messages, whether informative or error, are assigned a severity level. The severity level of an error message determines the damage caused by that error and whether that message can be suppressed. The severity level can be one of 0, 5, 10, 15, 20, 25, and greater than 25, which includes 99. Table 5.1 shows some examples.

Table 5.1. Error Messages and Severity Levels

Tip

Not every message with a severity level less than or equal to 25 can be suppressed. Error messages can be suppressed only for errors in which Forms can do away with the damage caused by the resulting error.

As an example, consider the message

FRM-40202: Field must be entered.

This message has a severity level of 15 and cannot be suppressed at all. The reason is that a mandatory item in a form should always have a value, irrespective of whether the resulting error message is suppressed.

Built-ins, Triggers, System Variables , and Exceptions

Oracle Forms has a set of built-ins, triggers, system variables, and exceptions to handle errors.

• Built-ins ” FORM_SUCCESS, FORM_FAILURE, FORM_FATAL, MESSAGE_TYPE, MESSAGE_CODE, MESSAGE_TEXT, ERROR_TYPE, ERROR_CODE, ERROR_TEXT, DBMS_ERROR_CODE, DBMS_ERROR_TEXT, SQLCODE, and SQLERRM (the standard PL/SQL functions to catch exceptions)
• Triggers ” ON-MESSAGE and ON-ERROR
• System Variables ” :SYSTEM.MESSAGE_LEVEL and :SYSTEM.SUPPRESS_WORKING
• Exceptions ” FORM_TRIGGER_FAILURE (to be raised explicitly with the RAISE built-in)

I will elaborate on each of these as we progress through the chapter. More specifically , I will address issues such as how to trap (suppress) informative and error messages using these different methods (that is, how to use the various system variables and triggers to trap messages).