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 setApplicationContextprocedure call to pass an ABL procedure handle to the Message Consumer object. The message handler can obtain the procedure handle by calling the getApplicationContextfunction in the Message Consumer object and can then make the appropriate internal procedure calls.
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: deleteSessionprocedure , deleteConsumer procedure, and recover procedure. There are no restrictions on calling these API entries of another Session object.
Message handlers should handle ERROR, STOP, and QUIT conditions and not propagate them. An unhandled condition is considered a programming error.