Class-based method call

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

Check if the ERROR-STATUS:NUM-MESSAGES attribute is greater than zero to see if the AVM generated error messages. ABL handle methods used in a block without a CATCH end block treat errors as warnings and do not raise ERROR, do not set the ERROR-STATUS:ERROR attribute, but do add messages to the ERROR-STATUS system handle. Therefore, this test is the better test for code using handle methods without CATCH end blocks. ABL handle methods used in a block with a CATCH end block raise ERROR and add messages to the error object generated by the AVM. In this case, the AVM does not update the ERROR-STATUS system handle.

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

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, then the information and messages in the error object will be 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.

Using the appropriate syntax, you can invoke the method as a statement (without returning a value) or invoke the method in an expression that uses the defined return value according to its data type. For information on ABL methods and their definition, see the METHOD statement reference entry. For information on the definition of a .NET method, see its entry in the Microsoft .NET, Infragistics, or other class library that defines it. For information on how .NET data types map to ABL data types, see the Data types reference entry.

If the method is defined as static, you can call the method whether or not an instance of its defining class exists.

If you reference an available method within a static constructor, static method, or static property accessor that is defined in the same class or class hierarchy as the referenced method, the referenced method must also be defined as static; attempting to directly reference an instance method that is defined in the same class or class hierarchy as the referencing static member raises a compile-time error.

In ABL, all private and protected methods are class based. A method marked as PRIVATE can be accessed from any instance of the class that defines it. Likewise, a PROTECTED method can be accessed from any instance of the defining class or subclass. In other words, an instance can access the PROTECTED method of a second instance of a class at the same level or higher in the class hierarchy.

From within an ABL class definition, you can typically invoke any instance method that is defined and available within the class hierarchy by referencing its method-name and any parameter list without a qualifying object-reference. However, if the method name is a reserved keyword, you must call the method using THIS-OBJECT as the object-reference. If the instance method is defined as an OVERRIDE method, you can invoke the method implementation that it overrides in the most derived class where it is defined using SUPER as the object-reference. For more information, see the reference entry for the SUPER system reference.

From within a class definition, you can typically invoke any static method that is defined and available within the class hierarchy by referencing its method-name and any parameter list without a qualifying class-type-name. However, if the method name is a reserved keyword, you must call the method using the qualifying class-type-name, even if the method is called from within the class that defines it. If the static method is defined as an OVERRIDE (redefining) method, you can invoke any static method implementation in the class hierarchy that it redefines by using the qualifying class-type-name of the class that defines the particular method implementation you want to call.

From outside a class hierarchy, you can only invoke an available instance method by referencing its method-name and its parameters qualified by an object-reference to the class instance where the method is defined; you can only invoke an available static method by referencing its method-name and its parameters qualified by the class-type-name of the class that defines the method as static. The only methods defined within a class hierarchy that are available outside the hierarchy are methods defined as PUBLIC.

You can call an abstract method either from within the class that defines it or on an object-reference defined as the type of the abstract class that defines it. Although an abstract method is defined without an implementation, at run time, the method is always implemented in a derived class. So, any reference to an abstract method is always resolved by the most derived class that implements it.

ABL has the following limitations on the .NET methods you can call:

You cannot call the static method, System.Windows.Forms.Application:DoEvent( ). In ABL, you can use the PROCESS EVENTS statement to handle both ABL and .NET events.

You cannot call the static method, System.Windows.Forms.Application:Run( ), outside of a WAIT-FOR statement. For more information, see the WAIT-FOR statement (.NET andABL) reference entry.

You cannot call the instance method, System.Windows.Forms.Form:ShowDialog( ), outside of a WAIT-FOR statement. For more information, see the WAIT-FOR statement (.NET andABL) reference entry.

You cannot call a .NET generic method. Similar to a .NET generic type, a .NET generic method has a name that is appended with a comma-separated list of one or more type parameters enclosed in angle brackets, for example, Add<T, S>(tVar, sVar). In this case, you would substitute .NET data types for the parameters T and S when you called the method. ABL does not currently support any reference to these methods. For more information on ABL support for .NET generic types, see the Data types reference entry.