Understanding condition handling in distributed ABL sessions
- Last Updated: August 24, 2023
- 1 minute read
- OpenEdge
- Version 13.0
- Documentation
The processing boundary that exists between an ABL client application session and a PAS for OpenEdge session influences how error conditions are viewed and handled in each session. The following table defines the four basic ABL conditions and describes how raising these conditions in one session affects the processing in the other, associated session.
| Condition | Description |
|---|---|
|
An unhandled ERROR condition raised in a client application has no
effect on any server sessions to which it is connected. Conversely, an
unhandled ERROR condition raised in a
server session has no effect on the client application to which it is
connected.Handling this condition conforms to standard ABL rules. For more information about these rules, see Develop ABL Applications. The only way a server session can raiseERROR in the client application is for a remote procedure
or an Activate procedure to execute the RETURN
ERROR statement. Either one raises ERROR on the RUN
statement in the client application, which can also be returned in a
CATCH block on the client.. |
|
An unhandled ENDKEY condition raised in a client application has no
effect on any server sessions to which it is connected. Conversely, an
unhandled ENDKEY condition raised in a
server session has no affect on the client application to which it is
connected.Handling this condition conforms to standard ABL rules. For more information about these rules, see Develop ABL Applications. A server session raises theENDKEY
condition if an attempt to find a database record fails or an INPUT FROM statement reaches the end of an
input stream. Like a batch client, there are no user-interface events
that can raise the ENDKEY
condition. |
|
A STOP
condition raised in a client application while it is executing a remote
procedure causes a STOP condition to be
raised in the context of the executing procedure in the server
session.An unhandled On a root client application — An unhandled
STOP condition causes the STOP condition to be propagated back to the client
application where it is raised again in the context of the outstanding
remote procedure request. It does not cause a restart of the server
session. All active remote persistent procedures and server session
connections remain intact. |
|
An unhandled QUIT condition raised in a client application disconnects
the client application from all server sessions it is connected to and
deletes the proxy procedure handles for that client application.An unhandled QUIT
condition raised in a server session results in the immediate,
successful completion of the current remote procedure request. The
client application is then automatically disconnected from the
server session.Note: Executing QUIT as the final
statement in the Disconnect procedure for a bound
session-managed connection causes the AVM to clear all context,
such as globally shared variables, from the server session
before it disconnects from the client. |