Saving a few lines of ABAP Code

Well whatever you could save now a days :)
Not that it's going to earn much interest from the Banks.

Just in case you are tired of reading numerous thoughts on the global credit crunch, business ethics, corporate social responsibility, sustainability and would like to enjoy the quantum of technical solace then you are in luck. Thomas Jung & other enterprise geeks have started a new Blog Enterprise Geeks . Also, if you are not very particular about reading SAP / ABAP horrors only :) then Coding Horror is another good read.

And if you want some plain geeky fun then grab a coffee and hold it tight ... Coffee Corner at SDN :) ..there you go.....

Actually, I just wanted to wish you all a very happy new year. So I am wishing now ( It's never too late ).

And if you are still reading....
Off the top of your head, do you remember a few ways to save some coding effort through better use of ABAP statements?  To add a few from my side :

I've found that some developers still use function 'FORMAT_MESSAGE' or a table T100 to get the message text  [ e.g. After a function call or BDC CALL TRANSACTIONS ]. This function 'FORMAT_MESSAGE' is also used in stanadard SAP programs [ may be in old ones ].

I think a better way is to use '...INTO text' variant of message statement rather than calling functions or actually writing 60 lines of code to select the data from table T100 and then replace the & with variables.

DATA lv_message_text TYPE string. 
CALL FUNCTION ... EXCEPTIONS error_message = 4. 
IF sy-subrc <> 0. 
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno 
INTO lv_message_text 
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. 
ENDIF.
* Now use lv_message_text to prepare your error report
Write : lv_message_text.
 

Another important point : Do you know what is the effect of having an exception error_message in the function call? Like 'When_Others', this is not a defined exception in the function interface. However, it can be specified for any function call.

Some of the standard function modules throw error messages without the raising clause and that means you can't capture/handle these messages from your calling program...unless you copy that standard function and make it civilized or else use this exception error_messages while calling the function.

If the error_message addition is specified after EXCEPTIONS, then you should be able to capture error messages in the calling program, even if the function module does not have the RAISING addition for those messages.

I guess, it's always safer to call standard functions with the error_message exception. I wonder why SAP does not add this in the pattern for function call.... like WHEN_OTHERS.

Add your tips/views in the comment section. But I wish you a very happy new year anyway :)