Errors are reported synchronously when something goes wrong at a method call. The problems can be either programming errors or run-time conditions. Examples include attempts to publish to an unauthorized topic or attempts to receive from a nonexistent queue.
An ABL API function reports problems synchronously by returning an Unknown value (?).
Some programming errors are not detected by the ABL–JMS API but rather by the ABL interpreter. For example, an attempt to call the setText procedure in a StreamMessage causes error 6456:
Procedure message.p has no entry point for setText. (6456)
To report a problem synchronously, the ABL–JMS API internal procedure calls:
RETURN ERROR <error-message>
This call raises an error condition at the caller. The caller can use regular ABL techniques to handle the error: a NO–ERROR phrase or an ON ERROR block, coupled with checking the RETURN–VALUE value to obtain the error message. If an application uses the NO–ERROR phrase, it must check the STATUS–ERROR:error flag to determine whether a problem has occurred.
By default, every synchronously reported error or condition is displayed by the ABL–JMS API, which calls:
MESSAGE <error-message> VIEW-AS ALERT-BOX.
This mechanism allows a quick analysis and resolution of the problem at development time. At deployment time, however, the application developer might want to handle problems programmatically and prevent the message from appearing. Calling the setNoErrorDisplayprocedure in the Session object suppresses the message display.
Note: Message objects inherit the display/noDisplay property from the session that created them. However, after a message is created, it is independent of the session. The setNoErrorDisplayprocedure must be called in the Message object itself to change this property.
