Runtime Exception ITAB_DUPLICATE_KEY behaves differently for CORRESPONDING and FOR loop

[tamitdassharma]

Hi Experts,

I think this is a shortcoming from SAPs side, the runtime exception ITAB_DUPLICATE_KEY behaves differently in case of CORRESPONDING component operator and FOR loop. In case of the former, the runtime exception cannot be caught. However, in case of the later there is an exception class CX_SY_ITAB_DUPLICATE_KEY which can be caught and handled. 

Scenario: Moving data from an internal table of type standard to internal table of type hashed.

Consider the following code.

TYPES:
  BEGIN OF _structure,
    id   TYPE i,
    name TYPE string,
  END OF _structure,

_standard_table_type TYPE STANDARD TABLE OF _structure WITH EMPTY KEY,
_hashed_table_type   TYPE HASHED TABLE OF _structure WITH UNIQUE KEY id.

DATA(itab1) = VALUE _standard_table_type( 
                ( id = 1 name = |Tamit| ) 
                ( id = 1 name = |Tamit| ) 
                ( id = 2 name = |tamit| ) 
                ( id = 3 name = |Tamit New| ) ).

Now if we create a hashed internal table from the above mentioned standard table using for the exception can be caught as displayed below.

TRY.
  DATA(itab2) = VALUE _hashed_table_type( FOR <itab> IN itab1 ( <itab> ) ).
    CATCH cx_sy_itab_duplicate_key INTO DATA(exception1).
      out->write( |Exception raised via For Loop| ).
      out->write( exception1->get_text( ) ).
      out->write( exception1->get_longtext( ) ).
ENDTRY.

Also, we can create the same hashed table using corresponding - component operator as shown below. But in this case the exception cannot be caught.

DATA(itab3) = CORRESPONDING _hashed_table_type( itab1 ).

 The question to the community is that shouldn't in both the case the exception be allowed to be caught as the runtime error is same in both the cases.

SAP NetWeaver Application Server for ABAP SAP S/4HANA Cloud ABAP Environment ABAP Extensibility 

[MichiFr]

Sure, this would be correct, fully acknowledge👍

[Sandra_Rossi · Accepted solution]

Reproduced in 7.52 SP 04.

As far as I can see in the documentation of CORRESPONDING, it says that to avoid a duplicate exception (doesn't say what kind of exception it is), DISCARDING DUPLICATES is to be used.

Now, what should happen exactly if a duplicate happens, according to the documentation and is that true if I test in ABAP?

The documentation of CORRESPONDING says that the insertion behaves like MOVE-CORRESPONDING (for itabs).

The documentation of MOVE-CORRESPONDING says that "Finally, and if necessary, the table keys and associated table indexes are updated in the target table in accordance with the rules for insertions in internal tables. The corresponding exceptions are raised if uniqueness is violated."

It's still not very clear what exact rules are managed for "insertions in internal tables", it behaves differently for one line at a time and for one set of lines (LINES OF).

If you use MOVE-CORRESPONDING, you get ITAB_DUPLICATE_KEY.

If you use INSERT one line without using LINES OF, the line is not inserted, SY-SUBRC is set to 4 and the program continues.

If you use INSERT LINES OF, you get ITAB_DUPLICATE_KEY.

The documentation of INSERT, line_spec > LINES OF seems wrong to me: "If there is a conflict with an existing unique table key, a catchable exception is raised when inserting multiple lines from an internal table."

If you look at the general documentation of INSERT - itab, you finally obtain the correct rule lost at the bottom of the page: "Uncatchable Exceptions Cause: When inserting a set of lines, entries with an identical key were produced (the target table is defined by UNIQUE). Runtime error: ITAB_DUPLICATE_KEY".

So, I guess that SAP could improve the documentation and clarify.

My tests:

DATA(itab3) = VALUE _hashed_table_type( ).
TRY.
    CASE 6.
      WHEN 1.
        " Runtime error ITAB_DUPLICATE_KEY if duplicate
        itab3 = CORRESPONDING _hashed_table_type( itab1 ).
      WHEN 2.
        " Runtime error ITAB_DUPLICATE_KEY if duplicate
        MOVE-CORRESPONDING itab1 TO itab3.
      WHEN 3.
        " Runtime error ITAB_DUPLICATE_KEY if duplicate
        INSERT LINES OF itab1 INTO TABLE itab3.
      WHEN 4.
        " SY-SUBRC = 4 if duplicate
        INSERT VALUE #( id = 1 name = |Tamit| ) INTO TABLE itab3.
        INSERT VALUE #( id = 1 name = |Tamit| ) INTO TABLE itab3.
      WHEN 5.
        " CX_SY_ITAB_DUPLICATE_KEY if duplicate
        itab3 = VALUE _hashed_table_type( FOR <itab> IN itab1 ( CORRESPONDING #( <itab> ) ) ).
      WHEN 6.
        " Discard duplicate lines
        itab3 = CORRESPONDING _hashed_table_type( itab1 DISCARDING DUPLICATES ).
    ENDCASE.
  CATCH cx_root INTO DATA(error).
ENDTRY.

[horst_keller · Accepted solution]

Indeed, there is a translation error in the documentation of INSERT LINES. The documentation was in German originally, where it read "unbehandelbare Ausnahme". Unfortunately. we are fighting, with lots of these. Corrected for 2411,