Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Question about using Assign Statement with Table Expression

sap_cohort
Active Contributor
0 Kudos

Just a quick question for all the ABAP Experts out there.
For the below code should I use SY-SUBRC = 0 for the ASSIGN Keyword or CATCH CX_SY_ITAB_LINE_NOT_FOUND for the Table Expression? Not sure how this works... Thanks for any insight!

" CHECK IF EMPLOYEE FOUND IN BPC MASTER DATA DIM TABLE 
ASSIGN <lt_employee>[ (lc_id) = <lv_employee> ] TO FIELD-SYMBOL(<ls_employee>).
1 ACCEPTED SOLUTION

Sandra_Rossi
Active Contributor

As said in the official ABAP documentation of ASSIGN table_exp TO <fs>:

In this variant, the statement ASSIGN sets the return code sy-subrc.

  • If the specified row is found, sy-subrc is set to 0.
  • If the row is not found, sy-subrc is set to 4, except when the end of the table is reached in binary searches in sorted tables. In this case, sy-subrc is set to 8.

If the specified row is not found, an exception is not raised (unlike in other uses of table expressions).

So, no need of using TRY...CATCH (unless you change the XXX of ASSIGN itab[ XXX ] such a way that it can raise an exception.

DATA(itab) = VALUE string_table( ).

ASSIGN itab[ 1 ] TO FIELD-SYMBOL(<fs>). " It doesn't need TRY/CATCH
ASSERT sy-subrc <> 0 AND <fs> IS NOT ASSIGNED.

TRY.
    ASSIGN itab[ 1 / 0 ] TO <fs>. " It needs TRY/CATCH
  CATCH cx_root INTO DATA(lx).
ENDTRY.
ASSERT lx IS INSTANCE OF cx_sy_zerodivide.
8 REPLIES 8

former_member1716
Active Contributor

Hello Kenneth Murray,

Using the expression in TRY and CATCH Block is a better way of coding.

You can also Use SY-SUBRC, the real problem arises when you try to use the Field Symbol.

In case if the Field Symbol assignment is not successful then the code will dump when the Field symbol is used further.

With Try Catch block you handle your Exception better, in case you go with SY-SUBRC just ensure when SY-SUBRC is not 0 don't use the field symbol further.

There is also another keyword as below in case if you are looking for options:

CHECK <fs> IS ASSIGNED.

Regards!

0 Kudos

I can see now the catch is best. Thanks

My concern with the statement is when the table expression fails (does not get a hit), will the exception occur inside the assign statement since a table expression does not set sy-subrc

So would I need to catch the exception for the table expression and check the sy-subrc for the ASSIGN as well?
I'm wondering what code would be the best way to handle both the ASSIGN and the Exception.

Hope this makes sense.

0 Kudos

OK, I was able to set up a test scenario and it looks like the Exception does not occur and I can just test for SY-SUBRC. Just have to watch the FS Symbol assignment as you say. Thanks!

Kenneth Murray,

Yes you are right.. You won't get a exception if the assignment is not successful, the issue arises only when the assigned field symbol is used further during un-successful assignment.

Regards!

michael_koehler2
Participant

Hi Kenneth,

As in many cases, the answer is 'it depends'.

In principle, Satish is right when he says the 'TRY - CATCH' is cleaner. But it also comes with a lot of baggage... You have to manage the exceptions, propagate, react, all that jazz. If your statement is within a larger environment that has an exception management strategy, that would be the approach I would take.

If, on the other hand, you just want a quick success check to, say, go left or right, depending on the success or failure of the ASSIGN - go with the SY_SUBRC. Quick, simple and without access baggage.

Hope that helps,
Mike

Sandra_Rossi
Active Contributor

As said in the official ABAP documentation of ASSIGN table_exp TO <fs>:

In this variant, the statement ASSIGN sets the return code sy-subrc.

  • If the specified row is found, sy-subrc is set to 0.
  • If the row is not found, sy-subrc is set to 4, except when the end of the table is reached in binary searches in sorted tables. In this case, sy-subrc is set to 8.

If the specified row is not found, an exception is not raised (unlike in other uses of table expressions).

So, no need of using TRY...CATCH (unless you change the XXX of ASSIGN itab[ XXX ] such a way that it can raise an exception.

DATA(itab) = VALUE string_table( ).

ASSIGN itab[ 1 ] TO FIELD-SYMBOL(<fs>). " It doesn't need TRY/CATCH
ASSERT sy-subrc <> 0 AND <fs> IS NOT ASSIGNED.

TRY.
    ASSIGN itab[ 1 / 0 ] TO <fs>. " It needs TRY/CATCH
  CATCH cx_root INTO DATA(lx).
ENDTRY.
ASSERT lx IS INSTANCE OF cx_sy_zerodivide.

0 Kudos

Thanks for catching the details on that. Greatly appreciated!

DoanManhQuynh
Active Contributor

I just want to add 1 more point here, if you using index inside table expression ( table[ number ] ) then its OK to wrap that code with TRY...CATCH, but if you are going to use component name (as your sample) instead and component name is wrong, then its become an uncatchable exception. So I think the best way to do it with component name is check the existence of component first:

DATA(ref) = NEW flighttab( ).
ASSIGN ref->* TO FIELD-SYMBOL(<f_flight>).
SELECT * FROM sflight INTO TABLE @<f_flight>.
"TRY..CATCH OK
TRY .
    ASSIGN <f_flight>[ 1 / 0 ] TO FIELD-SYMBOL(<f_line1>).
  CATCH cx_root.
    BREAK-POINT.
ENDTRY.
"Dump
TRY .
    ASSIGN <f_flight>[ ('CARRRID') = 'AA' ] TO FIELD-SYMBOL(<f_line2>).
  CATCH cx_root.
    BREAK-POINT.
ENDTRY.