The error handling behavior of some handle methods is different depending on whether or not structured error handling is in effect in the block where the method is called. It is in effect if you have a CATCH block and/or you are using the UNDO, THROW directive on the block.

Note: There are several ways to set the UNDO, THROW directive for a block. See Block Flow of Control and Condition Directives for more detail.

Without structured error handling, these handle methods do not raise an error when the method fails, even though it generates an error message. The AVM treats the error as if it is a warning. By default, the error message displays to the current output device but execution continues at the next line, as if no error occurred.

If not using structured error handling, it is important to check not only ERROR-STATUS:ERROR, but also ERROR-STATUS:NUM-MESSAGES to detect issues reliably.

To maintain consistency in your ABL code, you can use structured error handling so that all methods that issue error messages raise an error and can be detected consistently.

In this example, you cannot use the ERROR-STATUS:ERROR attribute to detect that something went wrong. However, the error messages are still saved in the ERROR-STATUS handle. Therefore, you should check NUM-MESSAGES instead::

DEFINE VARIABLE hSocket AS HANDLE. 
CREATE SOCKET hSocket. 
hSocket:CONNECT ("-H localhost -S 3333") NO-ERROR. 

IF ERROR-STATUS:NUM-MESSAGES > 0 THEN 
  RUN FailedSocketConnect.p.

If there is structured error handling on the block, the method raises an error, not a warning. The above code still works as-is since NUM-MESSAGES is greater than 0 whether it is a warning or an error. But with structured error handling you can alternatively code it by checking for ERROR-STATUS:ERROR, as in this code:

DEFINE VARIABLE hSocket AS HANDLE. 

DO ON ERROR UNDO, THROW: // for unexpected errors 
  CREATE SOCKET hSocket. 
  hSocket:CONNECT ("-H localhost -S 3333") NO-ERROR. 

  IF ERROR-STATUS:ERROR THEN 
    RUN FailedSocketConnect.p. 
END.

An alternative approach is to avoid using NO-ERROR and checking ERROR-STATUS, and instead use a CATCH block to detect issues. For example:

VAR HANDLE hSocket.

DO ON ERROR UNDO, THROW: // for unexpected errors
  CREATE SOCKET hSocket.
  hSocket:CONNECT ("-H localhost -S 3333").

  CATCH ex1 AS Progress.Lang.Error: 
    /* handle connection error here */
  END.
END.