Publish( ) event method

Publishes an ABL class event defined in the current class definition. Publishing an event causes any event handlers subscribed to the event to execute.

Return type: VOID

Access: PRIVATE

Applies to: ABL class events

Syntax
[ THIS-OBJECT : \| `class-type-name` : ] `event-name` : Publish ( [ `parameter` [ , `parameter` ] ... ] ) [ NO-ERROR ]

[ THIS-OBJECT : | class-type-name : ]

If event-name is a reserved keyword, you must prefix an instance event-name with THIS-OBJECT or a static event-name with the class type name of the current class definition. Otherwise use of these qualifiers is optional.

event-name

The name of a non-abstract event defined as part of the current class definition. At compile time, ABL verifies that event-name specifies an event whose DEFINE EVENT statement appears in the current class definition. This can also be the name of an inherited .NET abstract event that is implemented in the current ABL class.

( [ parameter [ , parameter ] ... ] )

Specifies zero or more parameters as defined for the event signature that you must pass to the Publish( ) method. The parameters you pass must match the parameters defined in the corresponding DEFINE EVENT statement with respect to number, data type, and mode, exactly as if you were calling a method defined with these parameters. Otherwise, ABL raises a compile-time error. Note that even if the method compiles, the AVM can raise a run-time error if an argument passed to a parameter has an ambiguous type during compilation that turns out to be incompatible at run time.

The Publish( ) method passes the same parameters to each event handler subscribed to the event. Note that any parameter results represent values returned from the last event handler to execute. However, the order of execution for event handlers is not guaranteed. Therefore, if you subscribe to multiple event handlers, you cannot be certain what event handler has returned the parameter values from the Publish( ) method.

Caution: Any values passed as INPUT-OUTPUT to a given event handler become input to the next event handler to execute for a given event. Because the order of handler execution for multiple event handlers is not guaranteed, you cannot be certain of the input values passed as INPUT-OUTPUT to any given event handler.

For more information on the syntax and requirements for passing each parameter, and on the behavior of parameters passed to the Publish( ) method, see the Parameter passing syntax reference entry.

NO-ERROR

Suppresses ABL errors or error messages that would otherwise occur and diverts them to the ERROR-STATUS system handle. If an error occurs, the action of the statement is not completed and execution continues with the next statement. If the statement fails, any persistent side-effects of the statement are backed out. If the statement includes an expression that contains other executable elements, like methods, the work performed by these elements may or may not be completed, depending on the order in which the AVM resolves the expression elements and the occurrence of the error.

For an ABL class event, if an event handler invoked by this method raises an error, the error is raised on this statement, and any event handlers that have not yet executed for the event do not execute. In this case, the error behavior and messages reflect the event handler that generated the error as if you called the handler directly. Note also that any STOP or QUIT condition is handled as if you called the handler directly.

Note also, if event-name is an ABL event that implements a .NET abstract event, and you invoke a .NET method within your handler that throws an exception back to .NET, .NET generates a System.ApplicationException that it throws back to the .NET method, which determines the result that you can manage in your handler.

To check for errors after a statement that uses the NO-ERROR option:

Check the ERROR-STATUS:ERROR attribute to see if the AVM has raised the ERROR condition.

Check if the ERROR-STATUS:NUM-MESSAGES attribute is greater than zero to see if the AVM has generated error messages.

Use ERROR-STATUS:GET-MESSAGE( message-num ) to retrieve a particular message, where message-num is 1 for the first message.

If the statement does not include the NO-ERROR option, you can use a CATCH end block to handle errors raised by the statement.

Following are some other important usage notes on the NO-ERROR option:

NO-ERROR does not suppress errors that raise the STOP or QUIT condition.

A CATCH statement, which introduces a CATCH end block, is analogous to a NO-ERROR option in that it also suppresses errors, but it does so for an entire block of code. It is different in that the error messages are contained in a class-based error object (generated by the AVM or explicitly thrown), as opposed to the ERROR-STATUS system handle. Also, if errors raised in the block are not handled by a compatible CATCH block, ON ERROR phrase, or UNDO statement, then the error is not suppressed, but handled with the default error processing for that block type.

When a statement contains the NO-ERROR option and resides in a block with a CATCH end block, the NO-ERROR option takes precedence over the CATCH block. That is, an error raised on the statement with the NO-ERROR option will not be handled by a compatible CATCH end block. The error is redirected to the ERROR-STATUS system handle as normal.

If an error object is thrown to a statement that includes the NO-ERROR option, the information and messages in the error object are used to set the ERROR-STATUS system handle. This interoperability feature is important for those integrating code that uses the traditional NO-ERROR technique with the newer, structured error handling that features error objects and CATCH end blocks.

To access more comprehensive error information for a .NET exception, use a CATCH end block instead of the NO-ERROR option. For more information on handling .NET exceptions, see the sections on .NET error handling in OpenEdge Development: GUI for .NET Programming.

You can only invoke the Publish( ) method on an event from within a class definition that defines and implements the event, regardless of the event’s access mode. (You cannot invoke Publish( ) on an abstract event.) Thus, you can publish the event within any method, constructor, destructor, property accessor, or trigger that is defined within the class that also includes the DEFINE EVENT statement that implements the event.

After the Publish( ) statement executes, the value of the RETURN-VALUE function reflects the last RETURN statement executed (if any) by all event handlers subscribed to event-name. However, because the order of handler execution is not guaranteed, if you subscribe more than one event handler that executes RETURN, you might not know which handler set the value for the RETURN-VALUE function.