6/18/2023 0 Comments Abap catch cx sy illegal itabFeel free to play with it or even send any updates back via GitHub. ![]() It was just a quick-n-dirty originally for comparing just two options and just grew as a copy/paste of alternatives. If we’re talking anything less than thousands in a short space of time then you can safely ignore the impact.Īfter several comments and suggestions, I uploaded my test program to GitHub at abap_itab_perf to use a single catch handler for multiple expressions), but be mindful of the expected failure rate and performance-criticality of the component. ![]() TRY-CATCH with table expressions can be a useful way to structure your code (e.g. ![]() (Yes, I know, ‘new’ ABAP can be used to make code either more readable or more cryptic, but that’s another discussion) For compact and/or readable code, use table expressions.If performance is number 1 priority and you need the data, READ TABLE is fastest.If you don’t need the data, line_exists( ) is fastest.line_exists( ) became a poor choice in my scenario, because we need to double up the the search in order to also read the record:.the exception was no longer an influence (to be expected).I suspect that this applies to CATCH blocks in general, but that’s another analysis for another day.įor comparison, I also re-ran the same but this time with a lookup value that did exist. I’m happy to sacrifice a little performance for readability, but this is a significant impact. So the take-away here for me is that a TRY-CATCH may be easier to read, but should not be used in performance-sensitive code unless you expect the values to be found most of the time. I tested a million failed lookups on a 7.50 HANA system. Here are the results in microseconds: line_exists( ) : 610,758 ASSIGN itab – which (bizarrely) sets SY-SUBRC instead of producing an exception.The trusty READ TABLE … WITH KEY, with and without TRANSPORTING NO FIELDS.Results:įor completeness, and additionally with suggestions by Former Member, Quynh Doan Manh and Uwe Fetzer in the comments, I also added a couple of other ways to look for an entry in a table: I mean, why use x = VALUE #( y ) when you can just write x = y? The VALUE constructor’s sole purpose here is the OPTIONAL bit that lets us do away with the exception.Īs I was working on a performance-sensitive component, I tested it to see what performs best. This particular usage of VALUE may seem a little awkward. If the matching entry cannot be found, you need to catch the exception: TRY.Īnother alternative is to use a VALUE constructor expression where you can add the keyword OPTIONAL (or DEFAULT) to just initialize any non-found values. So the following READ TABLE can be rewritten using a table expression (the bit in square brackets): READ TABLE itab INTO row WITH KEY id = find_id. I have a table that includes a field “ID”. With table expressions, finding an entry in a table is really neat. Quick primer for those still getting accustomed to 7.4 ABAP (feel free to skip to the results): The unexpected result was that when a row can’t be found, using table expressions with exceptions is ten times slower on average than all other lookup methods, including the good ol’ fashioned READ TABLE with SY-SUBRC. My scenario involved internal table searches where the values would be missing a lot of the time. (include) program "CL_AGS_RI_MONID=CM002".Ĩ3 DATA(lt_selopt) = VALUE #( -metric_parameters-low.I got a blog-worthy surprise when I did a quick performance test on two different ways to use the new-ish (7.4) table expressions to perform a search on an internal table. The procedure is in program "CL_AGS_RI_MONID=CP". This exception was not handled locally or declared in the RAISINGĬlause in the procedure's signature however. The termination is due to exception "CX_SY_ITAB_LINE_NOT_FOUND" occurring in In the source code, the termination point is in line 85 of (Include) The termination occurred in ABAP program "CL_AGS_RI_MONID=CP", If only index accesses are used in statements with multiple table expressions, it is not possible to distinguish which expression was unsuccessful. Row index (for "INDEX" access) / key name (for "KEY" access): 1. The exception class CXSYITABLINENOTFOUND contains attributes for displaying the row number in the index or key used when a row cannot be accessed. Since the caller of the procedure could not have anticipated thisĮxception, the current program was terminated. "GET_ALL_MONIDS" "(METHOD)", nor was it propagated by a RAISING clause. TheĮxception is assigned to class 'CX_SY_ITAB_LINE_NOT_FOUND' and was not caught ![]() Within SAP Solution Manager 7.2, attempting to update the AKF Repository for the BPA Twincubes connector instance within Business Process Improvement - Administration fails with the following shortdump:ĪBAP Program CL_AGS_RI_MONID=CPĪn exception has occurred which is explained in more detail below.
0 Comments
Leave a Reply. |