Error Handling › Design Error Handling in Applications › Server Error Handling › Use Server-Supplied Error Information

Use Server-Supplied Error Information

For complex applications, the server-supplied error information technique provides a robust technique to error handling. This technique eliminates the disadvantages of the other error handling techniques such as client distribution, maintenance, and lack of flexibility. The cost of these advantages is that the application must build and maintain the error message architecture. The type of application that may best use this approach is one with a large number of clients that may have messages change regularly.

With this technique, the server sends all the error information back to the client. This technique isolates the client procedures from changes in server errors. The error information may include the error code, the message text, and the message type (Error, Warning or Informational).

The server contains an action block that converts the exit state to a code and populates the other information. To populate the message and the type fields, the action block can use either set statements to assign literals, or read from a server-based table that contains that message information. The server table option provides the greatest flexibility because a message or message type can be changed without a logic change. For more information, see Create an Error Data Table.

After the message is assigned or read, it is returned using data returned on the flow or view matched with the remote use statement.

After the message information is assigned, the procedure sets one of two exit states to trigger the return flow to the client. One exit state is used when a rollback is necessary and the other when a rollback is not necessary. The exit state used for rollback is defined with the rollback property set.

The exit states should be defined with a message type of “none” to prevent any unwanted message displays.

If a flow is used for the procedure interaction, define the flow returns on property as Execute First.

At the client procedure, if a server message needs to be displayed (determined by evaluating the message type), the client will flow, using a link, to an error message display procedure. It will send the message using view matching on the flow.

All clients in the business system should reuse the error message procedure.

The following list explains advantages of this technique:

• The client is isolated from having to process server error messages.
• All the client does is check the error type code to determine if a message needs to be displayed and display the error message sent by the server. The server can add or change error messages without impacting the client. As a result the client procedure is easier to maintain.
• The distribution of data or load modules caused by message changes at the server are eliminated because all information is stored centrally.
• This makes management of the production environment simpler.

The following list explains disadvantages of this technique:

• Appearance of the message dialog box.
• CA Gen does not have the capability to display the error, warning, and informational bit map icons on the dialog box.
• You must develop all the logic to support server errors.