MESSAGE xxxx RAISING xxxx

In general, exceptions in a function module are handled by means of RAISE EXCEPTION. This sets a return code which is passed back to the calling program. 

For eg., let us consider an example of a function module SXXXX, which would create a purchase order with reference to a Purchase Requisition. The import parameter for this function module is Purchase Requisition number and the export parameter is the Purchase Order number created here. Assume that after a PR is created, a material is moved from one plant to another. Now during the PO creation, because of this mismatch the PO would not be created.  

In a normal case, if there is any mismatch, we generally use RAISE EXCEPTION XXXX. This would stop the function module from further processing and returns to the calling program with just the return code. But the calling program would never know the material number that caused this error.  

Now, instead of raising the exception using RAISE EXCEPTION, we would use the following statement:  

MESSAGE E309(06) with ‘xxx’ Raising XXXX.  

Using the above statement is similar to the usage of RAISE EXCEPTION, except for:

• If the call to the function module does not handle EXCEPTIONS, then the message is issued (in this case the error message is issued)

• If the calling program handles the exception, then no message is issued. The calling program would have the message details in the standard message variables SY-MSGID, SY-MSGV1 and others. So in our case, the calling program would have the information about the material and plant combination that triggered the exception.