8

An official SAP presentation discussing new ABAP programming features in NetWeaver 7.4 (CD261) makes a big deal about table expressions, replacing the old syntax to read from an internal table:

READ TABLE lt_aufk INTO ls_aufk WITH KEY aedat = sy-datum.
lv_order = ls_aufk-aufnr.

with a single-line lv_order = lt_aufk[ aedat = sy-datum ]-aufnr.

However, it fails to mention that if a table expression fails to find a line it will raise exception CX_SY_ITAB_LINE_NOT_FOUND, so really that notation should actually be:

TRY.
        lv_order = lt_aufk[ aedat = sy-datum ]-aufnr.
    CATCH cx_sy_itab_line_not_found.
ENDTRY.

Which is both longer and makes any simple read logic look incredibly complex and hard to read. Since every individual read might need to fail or succeed individually this quickly balloons out of proportion:

TRY.
        wa1 = lt_itab[ col1 = ... ].
    CATCH cx_sy_itab_line_not_found.
ENDTRY.
TRY.
        wa2 = lt_itab[ col2 = ... ].
    CATCH cx_sy_itab_line_not_found.
ENDTRY.
TRY.
        wa3 = lt_itab[ col3 = ... ].
    CATCH cx_sy_itab_line_not_found.
ENDTRY.
TRY.
        wa4 = lt_itab[ col4 = ... ].
    CATCH cx_sy_itab_line_not_found.
ENDTRY.
TRY.
        wa5 = lt_itab[ col5 = ... ].
    CATCH cx_sy_itab_line_not_found.
ENDTRY.

Is there any way to improve the readability of these table expressions? Am I using them improperly?

Lilienthal
  • 4,327
  • 13
  • 52
  • 88
  • Combine them into a single try/catch block for starters. – Jorg Nov 02 '14 at 08:55
  • @Jorg `every individual read might need to fail or succeed individually` In those cases that is not an option. – Lilienthal Nov 03 '14 at 08:30
  • Ahh sorry I missed that. Are you always reading the same date field? In that case you can move it to a method and keep the read dynamic maybe – Jorg Nov 03 '14 at 09:01
  • That's one option to streamline it somewhat but this is just an example for the generic case of reading WAs from itabs. I was hoping there was perhaps some obscure trick to disregarding the exceptions in a block but I guess I'm stuck with this syntax. Though even if it existed, ignoring exceptions probably wouldn't be a best or even accepted practice. – Lilienthal Nov 03 '14 at 09:21

3 Answers3

4

I was typing a comment but it's getting to long...

Best practice

This is debatable I guess but my 2 cents: Sometimes ignoring an exception is OK, for instance if you just want to, in your case, display an empty cell. Technically, in the old scenario you should also be catching SUBRCs before moving into structures too. You have an additional issue - depending on your table definitions, I can't see those - that aedat might not be a primary key in which case you might be trying to cram another table type into a work area. The thing that matters most in the end is whether or not your program crashes, and whether or not you're displaying meaningful data.

As for design principles, over the whole I think I'd rather put some effort into the DRY principle if you do a lot of this in your program.

Having said that, the documentation mentions:

About the exception:

Source

There are ways around it.

If the specified row is not found, a handleable expression of the class CX_SY_ITAB_LINE_NOT_FOUND is raised in all operand positions, except when

  1. a default value is specified in the definition of the type of the result,
  2. a table expression is used in the statement ASSIGN, where sy-subrc is set to the value 4,
  3. when used in the predicate function line_exists, where the logical value "false" is returned,
  4. when used in the table function line_index, where the value 0 is returned.

Default values for table expressions

Source.

Neat if you're on SP08 or higher already:

Table expressions itab[ ...] cannot support sy-subrc. Up to now, an exception was raised anytime if a table line specified in the square brackets could not be found. Not everybody liked this behavior.

As a workaround, you can place a table expression inside a VALUE or REF expression, that contains a OPTIONAL or DEFAULT addition. If a line is not found, the OPTIONAL addition returns an initiial line while the DEFAULT addition returns a given value, that can be specified as an expression, especially another table expression.

TYPES:
  BEGIN OF line,
    id    TYPE i,
    value TYPE string,
  END OF line,
  itab TYPE SORTED TABLE OF line WITH UNIQUE KEY id.

DATA(def) = VALUE line( id = 0 value = `not found` ).


...

DATA(result) = VALUE #( itab[ id = ... ] DEFAULT def ).
Jorg
  • 7,219
  • 3
  • 44
  • 65
  • SP8 seems to indeed provide an alternative. For the example above the code would be `wa1 = VALUE #( lt_itab[ col1 = ... ] OPTIONAL ).`. Unfortunate that we only just upgraded to SP7 so I guess I'll have to deal with ugly code for now. – Lilienthal Nov 03 '14 at 10:38
  • Can confirm that the `DEFAULT/OPTIONAL` parameters work as expected now that we've upgraded past SP08. – Lilienthal Aug 26 '15 at 08:52
0

You can use like below which is more similar to the read table syntax. Otherwise you need to use TRY CATCH for each expression if there is a probability the search fails.

ASSIGN lt_aufk[ aedat = lv_dat1 ] TO FIELD-SYMBOL(<ls_aufk>).
IF sy-subrc EQ 0.
  lv_order1 = <ls_aufk>-aufnr.
ENDIF.

ASSIGN lt_aufk[ aedat = lv_dat2 ] TO <ls_aufk>.
IF sy-subrc EQ 0.
  lv_order2 = <ls_aufk>-aufnr.
ENDIF.
...
Ali Varli
  • 189
  • 1
  • 6
-1

I think you should enclose all your read table in one try catch

Deirgis
  • 1