Designing the Procedure Interaction › Exit States › Exit State Definitions

Exit State Definitions

Exit state definitions can be built using system defaults or from any tool that can reference exit states. In a CA Gen action diagram, exit states are set according to the action performed and its outcome.

The outcome of an action may be signaled by the following values:

• Return condition of a data action (for example, WHEN NOT FOUND)
• Value of a return code attribute exported from a USED Action Block (for example, processing successful)
• Value of an Exit State returned to a client from a server procedure (for example return WITH ROLLBACK)

These are the options for ensuring an appropriate exit state is always set:

• Set an exit state only after each action is successfully achieved or each exception condition is discovered.
• You must ensure that every possible exception condition is identified.
• Set a positive default exit state at the beginning of the procedure logic, then test for each “positive” outcome and every exception that can be foreseen, and reset the exit state accordingly.
• The default value is used if no other exit state value is set.
• You must ensure that every possible exception condition is identified, to avoid giving a false positive result.
• This is currently the most widely adopted option.
• Set a negative exit state at the beginning of the procedure logic, then test for each successful outcome that is part of the procedure specification and reset the exit state accordingly.
• You must ensure that every possible exception condition is identified.
• The default value is also used if no “positive” or known “negative” exit state value is set. This ensures that any unexpected exception condition will not be assumed to be a successful outcome.

For ease of logic design and maintenance, each organization should try to adopt a single, consistent option for all client, server, and common action block logic. Where a mixture of these options is already adopted, be especially aware of which option is employed by existing logic with which their procedures must interwork.

This example raises the following issues:

• Exit State is set to “Processing OK” before any other logic is executed (line 4). You assume that positive conditions are not addressed in the USED action blocks. Therefore, you initialize exit state to the positive condition here. This avoids handling exception conditions throughout the remainder of the procedure logic.
• If Exit State is never set to a different value as the result of an exception, the positive condition will remain set. This design approach may not be safe unless you can guarantee correct handling of all exception conditions that may arise. For example, exception conditions could arise if the action blocks were subsequently modified.
• There is no handling of the exit state if the command sent to the procedure is not included in the case of command. This will be handled using one of the client/server error handling techniques.

It is essential that all action diagrams are compatible with the exception handling of any USED action blocks, and that exception conditions are handled completely and safely. When an exit state is set during a procedure execution, the results must be unambiguous.

These are the rules governing the assignment of exit state definitions to flows:

• An exit state value may appear on the flows on exit state list of only one flow from a given procedure.
• No exit state value that appears on the returns on exit state list of a link to a given procedure may appear on a flows on exit state list of flows from the same procedure.

More information:

Error Handling