The following topics explain the useful techniques associated with using error entities and error patterns when modeling a host application, specifically when dealing with character mode host applications. Using error conditions helps you to detect when an error has occurred while you're modeling and testing your host application model. Error patterns catch error messages displayed on the current entity, while error entities handle errors that result in a host error screen being displayed.
When creating both error patterns and error entities, it's possible to create a customized error message that enables you to detect what kind of error has occurred during an operation.
Note: In the Design Tool, if an error occurs and an operation completes before an error pattern is displayed or an error entity is reached, then error processing will not occur. For example, if an operation's destination entity is the same as its start entity and an error message is expected to display when the destination is reached, the action triggered by that error message may be bypassed. The operation needs to include a command, like a WaitForCursorAtLocation command, that ensures that the error pattern is displayed or the error entity is reached before the operation completes.
When handling an error condition, you sometimes have the choice of setting up an error pattern or an error entity. When evaluating which to use, review the FAQ on this topic and remember that error patterns require less processing overhead and are therefore recommended. If you're dealing with a problem associated with a starting screen, you will need to use an error entity.
Trapping error messages that result from writing attribute data to the terminal screen is often helpful in identifying errors. This is usually applicable to character mode host applications that produce error messages while you are writing data to the terminal screen.
The example below catches an error by creating an error pattern.
A user-defined error entity enables you to handle a host error screen by defining a custom error message or returning attribute data as your error message when the error entity is encountered. Make sure to define an operation on this error entity that enables you to navigate back to your original entity. Do not define an error entity as your home entity; if error handling is required, use error patterns instead.
To define an error entity:
Note: You can choose to define error entities in operations or in procedures. If you are using procedures, you can choose to add the error entity to your procedure. If you've already defined an error entity in an operation, it is not necessary to also define an error entity in your procedure. To define a custom error message when using procedures, use the Procedure Editor. Additionally, the error message feature within the Procedure Editor does not allow you to assign the contents of an attribute to the error message.
For more information, see the error pattern and error entities questions on the FAQ page.