This section provides information about handling of errors and conditions with the ABL–JMS API.
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 SonicMQ API Reference, which is installed in sonicmq_docs\sonicmq_api under the SonicMQ installation directory (open index.html in this directory, or access SonicMQ API Reference from the SonicMQ Documentation Portal).
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.
Note: For a complete description of ABL error handling, see OpenEdge Development: Error Handling.
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).
