DO and DO
Personally I hate nested IF … ENDIF. Suppose the following:
READ TABLE some_table WITH KEY ... IF sy-subrc = 0. READ TABLE some_other_table WITH KEY ... </li> IF sy-subrc = 0.</li> READ TABLE another_table WITH KEY ... </li> IF sy-subrc = 0. ... etc, etc.. ENDIF. ENDIF.ENDIF.
“Most disturbing, sir” as Jeevse could put it. Very unpleasant.
And the idea’s come. Now instead of nested IF’s I use DO..ENDDO, just as follows:
DO 1 TIMES. READ TABLE some_table WITH KEY ... CHECK sy-subrc = 0. READ TABLE some_other_table WITH KEY ... CHECK sy-subrc = 0. READ TABLE another_table WITH KEY ... CHECK sy-subrc = 0. ... etc, etc..ENDDO.
That’s it. What do you think?
To be honest my support team is not aware of the method, I'm keeping this quiet 🙂
It took me quite some time to realise, the need for DO ...ENDDO. Let me know if it is still right, the use of CHECK , when it fails, just comes out of the loop, not out of the program.
So according to this logic, the error message would be say
a) because of 1st read fail
b) because of 2nd read fail
c) because of 3rd read fail
and note exactly pinpoint. That would do I guess.
Yes we can put better error messages.
Thanks for sharing this, and as Scott rightly pointed out, this should do "barely okay" with support team.
Regards,
Subramanian V.
CHECK does not come out of the loop, it strictily goes to the next step of it, literally it equals to
And as in my case we have only one step in loop (DO 1 TIMES) then this is the equivalent of the exit. Actually, one can use TRY ENDTRY for the same purpose, but seems that the overhead of OO-exceptions would be slightly more than adequate.
Regards, Sergei
Thanks for the tip, hope you have other cool ones.
Peter
But a great idea, I like it.
That reminds me of a strange CASE I've seen:
CASE 'X'.
WHEN FLAG_1. ...
WHEN FLAG_2.
WHEN FLAG_3.
WHEN OTHERS.
ENDCASE.
Best regards
Dirk
Some 20 years ago I used to write programs on a proprietary ALGOL-like language, and there was a so-called static exceptions: something like TRY.. ENDTRY with explicit declaration of an exception and without generating exception instance when firing (just conversion into simple GOTO). The construct was very useful and readable. Would be nice to use something similar in ABAP.
in my eyes this is bad programming practice.
1. What do you do with error handling?
Normally you should use the else statement to do some error handling or write log entries so that one can reproduce why a program worked as it did.
2. You have no overview about the program flow.
Where did your program leave the do loop? You can only get it in the Debugger.
Sorry for that bad judgment but I´m basically a Java developer with also some years of programing practice in ABAP and things like this always bothered me.
Regards
Helmut
Certainly this is not an ideal pattern to use everywhere instead of nested IF's, I use it more-or-less locally just to make some fragments more readable (to me at least). There are some cases where there is no need to perform thorough error handling after each statement.
It is essential to use 1 TIMES clause in this sample as it garantees that DO loop would have only one pass. In that case you can treat DO 1 TIMES as BEGIN and ENDDO as END.
I admit that e.g. OO exceptions are much more powerful and readable but they have (as far as I know) essential overhead - instance creating, propagation etc.
if you don't want to, there is not an essential overhead with class based exceptions!
As long as you don't use INTO behind CATCH, there is no exception object created.
Regards
Horst
Ceratinly I experience some lack of knowledge of insides of OO exceptions. Could you provide some info on rasing exception overhead? If it's comparable with DO...CHECK...ENDDO, than it is certainly worth to switch to.
Regards, Sergei