This topic provides information about handling of errors and conditions with the ABL–JMS API. To configure logging, see Configure logging for the Progress OpenEdge JMS adapter.

From the point of view of the ABL programmer, there are two types of errors and conditions, programming errors and run-time conditions:

• A programming error is an erroneous sequence of calls to the ABL–JMS API, or the calling of the API with invalid parameters. Typically, programming errors should not occur in a deployed application. An example of a programming error is an attempt by the application to make a TextMessage call such as setText procedure, setLongText procedure, and appendText procedure in a StreamMessage. Programming errors should be tracked down and fixed at development time. The primary source of information for that phase is the ABL–JMS API (see ABL-JMS API Reference).
• A run-time condition is an event that disturbs the normal flow of the application. Such events can occur in a deployed application, so the ABL programmer should try to handle them programmatically. Examples of run-time conditions include attempts to connect to a JMS server that is not currently running, and attempts to subscribe to a topic without the proper authorization. For information about programmatically handling run-time conditions, refer to the API reference of your JMS provider.

A second criterion for classifying errors and conditions is whether the problem is reported by the ABL–JMS implementation synchronously or asynchronously:

• A problem is reported synchronously if it occurs and is detected while the OpenEdge application is executing an ABL–JMS API call.
• A problem is reported asynchronously when it comes from the asynchronous error reporting system of the JMS server (OnException Events) or from the ABL–JMS mechanism that delivers messages asynchronously to the OpenEdge client.

Programming errors are usually reported synchronously. Run-time conditions are reported either synchronously or asynchronously.