Error Handling after Calling a Method 

Purpose

Error handling in Desktop Office Integration can be a complex matter. The methods that you use can return a wide range of error codes. Furthermore, since Desktop Office Integration is being developed further, new error codes will appear in further releases. The following notes should make Desktop Office Integration easier to use.

After calling a method, you must find out if the call was successful. All methods contain a return parameter called ret_code, which contains the value ‘OK’ if the call was successful, or an error code if an error occurred. The class c_oi_errors contains symbolic constants for the ‘OK’ value and for all other error codes. Each method also stores additional error information. You can use the class method raise_message in class c_oi_errors to display a message in the status bar containing the precise cause of the error. The raise_message method executes the ABAP statement MESSAGE when an internal error occurs, and displays a message from message class SOFFICEINTEGRATION.

Use the following two processes as guidelines for your error handling. The first process does not investigate any errors in detail. The second process deals explicitly with some errors, and uses the raise_message method to display the rest.

If you do not synchronize the automation queue when you call methods (see the generic parameter no_flush), the value of the ret_code parameter is meaningless. This is because the value can only be set after the automation queue has been synchronized. Each method call returns a reference to an error object (error). Process III explains how to use the error object.

Process I

1. When you have called a method of the SAP Desktop Office Integration, call the class method show_message of class c_oi_errors:

  CALL METHOD C_OI_ERRORS=>RAISE_MESSAGE

           EXPORTING TYPE   = type

Use the type parameter to pass the message type (A, E, W, I, S).

If an error occurred in the execution of the SAP Desktop Office Integration method, the system displays a message of the corresponding type. The correct message text is determined automatically by the class method raise_message.

Process II

1. When you call a method of the SAP Desktop Office Integration, pass a variable ret_code in the call, in which the error code can be stored.

2. Check first whether an error has occurred at all. If no error occurred, branch directly to the section of the program that carries on with ‘normal’ processing.

3. Next, check whether an error occurred that you want to handle explicitly. In this case, branch to the section of the program that handles that error.

4. For all other error codes, you must call the class method raise_message of class c_oi_errors as described in process I.

Example of process II:

IF ret_code EQ c_oi_errors=>ret_ok.

    " Document opened successfully

ELSEIF ret_code EQ c_oi_errors=> ret_document_already_open.

    " Special error handling, e.g. dialog box.

ELSE.

   CALL METHOD c_oi_errors=>raise_message

       EXPORTING type   = 'E'.

ENDIF.

Process III

  1. Create an internal table to hold references to any error objects:
    DATA: errors TYPE REF TO i_oi_error OCCURS 0 WITH HEADER LINE.
  2. After each method call in which you set the parameter no_flush = ‘X’, insert the object reference into the internal table:
    CALL METHOD control->get_link_server
          EXPORTING server_type  = server_type
                    no_flush     = 'X'
          IMPORTING link_server  = link_server
                    retcode      = retcode
                    error        = errors.
    APPEND errors.
  3. Once you have synchronized the automation queue (either by setting the parameter no_flush = ' ' or by calling the method cl_gui_cfw=>flush), you can process the references in the error table:
    LOOP AT errors.
      CALL METHOD errors->raise_message
             EXPORTING  type     = 'E'
             EXCEPTIONS message_raised = 1
                        flush_failed   = 2.
    ENDLOOP.
    FREE errors.