Skip to Content
Technical Articles

CALL FUNCTION and catch errors without exceptions

I posted this content on LinkedIn a while back, but this is obviously where it belongs… If I recall the story correctly, since it was a few years ago now, I was working in a WM project the first time I needed to know what I’m about to describe here.

We were building a couple of SAPUI5 apps to support the warehouse process and one of the the function modules we used was failing from time to time without even causing short dumps. After we had scratched each others heads for a while, the debugger was the way forward and there it was at last: a MESSAGE statement of type E in the code. (And just a note: “from time to time” might sound random, but when we found out the root cause here, it was obviously fully logcal in itself, as always)


To demonstrate, here is an demo example of a function module that adds a number of days to a todays date:

FM implementation

If the supplied number of days to add is 0, no_number is raised. (line 13-15). And if it’s below zero, negative_number is raised. (line 17-19). These two would be caught and affect the sy-subrc for program flow after the normal FM call.

But then we also have the case where the supplied number of days is 73. (line 21-23). For some reason the demo FM does not want to handle this, but instead of using a declared FM exception, a MESSAGE is raised. Now, if this is run inside of the SAP GUI, the message will be displayed in the message bar, as expected, and the program flow will be stopped, as expected. But now that we are calling the FM without the GUI, like for instance when we are building SAPUI5 that is living outside of the SAP GUI, there is nowhere to display this message and then we got the abrupt crash of the FM without the short dump.


Typically, I use the CALL FUNCTION template to get the entire signature of the function module in the code, enter needed and remove what is not needed. And I expect to get the errors from the function module or BAPI call as exceptions to investigate in the sy-subrc (or a separate table or structure in some cases).

FM call

Like for no_number and negative_number in the example here:

This is what is provided from the template of the CALL FUNCTION. However in our case with the WM apps, and I have seen a couple of more after that, this error was not part of the exception handling of that function module.


Well, first off, if you are writing Function Modules like my example above, please stop! 😎 Don’t MESSAGE out into the void like that if there is no SAP GUI. But here’s what to do to catch-them-all…

As the documentation of CALL FUNCTION, parameter list, addition 6, clearly states:

Messages of the type E and A raise the exception error_message and set sy-subrc to n_error. The message class, message type, message number, and the content of any placeholders of the MESSAGE statement are in the fields sy-msgid, sy-msgno, sy-msgty, and sy-msgv1, … sy-msgv4.

In other words, this is the way to call the function module in order to also catch these abominations of FM errors:

FM call

By adding the error_message exception to the CALL FUNCTION we will also catch any MESSAGE of type A or E and we will have the detailed information about the message in the sy structure.

Even though the vast majority of Function Modules behave properly in this aspect I would think that the more we move outside of the SAP GUI, the more we might see these cases. And most of them will probably be to user exits and enhancements.

I hope that this might save somebody from some debugging and troubleshooting. 😊

You must be Logged on to comment or reply to a post.
  • HA!   Nice catch.   I've been known to spend days.  Yes, no typo there days in debug to find just one line of code that needs to be changed.  See your own example above.   Anything that can help bring me out of debug and into doing a fun project is a huge advantage to me!

    Thank you for the tip & the post here.   I don't always check linkedin.  😉


  • Thank you for the detailed blog.

    We will move from SAP GUI to fiori but we will continue to use this old function modules. This is a good blog to bookmark. 🙂


  • Great suggestion!

    BTW, a very odd quirk I noticed. This code works, and the exception is caught by zfoo’s caller.

    If someone not throwing that exception calls it, it just dumps, couldn’t find a way to catch it short of forking another process.

    function zfoo
        perform bar.
    form bar.
      perform baz.
    form baz.
      raise error_occured.
  • Many years ago I started to add the ERROR_MESSAGE exception to all my FM calls just in case but there was a gotcha.

    For the REUSE_ALV function modules (this is how long ago I am talking about) they NEED to be able to raise an error message and it not be caught by the calling program. This is for when there is an error message raised during user-command processing. The idea is to return to the ALV screen in such a case but if the caller catches the error message than the program ends.


    • Aha, there's the use case for not catching error_message.

      And I guess in general, when everything was either screen processing or running batch jobs, it kind of made sense to MESSAGE TYPE 'E' since it always had it's designated destination.

      It's just that it's 2020 now, really really close to 2021... 😊


      Take good care, Paul!