Try OpenEdge Now
skip to main content
Messaging and ESB
Implementing Messaging : Error and condition handling : Message handler errors and conditions

Message handler errors and conditions

A message-handling procedure is an arbitrary ABL program, and the programmer is free to use any ABL technique to handle problems that occur during the processing of a message. However, the following issues and limitations exist:
*Message handlers should handle ERROR, STOP, and QUIT conditions and not propagate them. An unhandled condition is considered a programming error.
*Since the message handler returns control to the ABL–JMS implementation and the message handler cannot raise a condition, there must be a mechanism to allow the message handler to communicate problems to the rest of the OpenEdge application. You can use the setApplicationContext procedure call to pass an ABL procedure handle to the Message Consumer object. The message handler can obtain the procedure handle by calling the getApplicationContext function in the Message Consumer object and can then make the appropriate internal procedure calls.
*As mentioned in Message acknowledgement, forwarding, and recovery, the message handler can call the setNoAcknowledge procedure of the Message Consumer to prevent the message from being acknowledged in a session that is not transacted for receiving.
*Calling WAIT–FOR is allowed inside a message handler, but no further messages from that Session object are received until the message handler returns.
*The following recursive calls from the message handler into the ABL–JMS API of the same Session object are considered programming errors: deleteSession procedure , deleteConsumer procedure, and recover procedure. There are no restrictions on calling these API entries of another Session object.