RETURN statement

The RETURN statement ends processing. What happens next depends on the programming context in which the RETURN statement is issued.

Syntax

Main Function

When used in the Main function, the RETURN statement stops processing of the module and returns control to the next node in a message flow. In the Main function the return statement must contain an expression of BOOLEAN type. The behavior of the RETURN statement in the Main function is dependant on the node. In the Compute node for example, if expression is anything other than TRUE, propagation of the message is stopped. In the Filter node, however, the message is propagated to the terminal matching the value of expression: TRUE, FALSE and UNKNOWN. The following table describes the differences between the RETURN statement when used in the Main function of the Compute, Filter, and Database nodes.

Node	RETURN TRUE;	RETURN FALSE;	RETURN UNKNOWN (if BOOLEAN type) or RETURN NULL;	RETURN;
Compute	Propagate message to Out terminal.	Stop propagation	Stop propagation	Deploy failure (BIP2912E: Type mismatch on RETURN)
Database	Propagate message to Out terminal.	Stop propagation	Stop propagation	Deploy failure (BIP2912E: Type mismatch on RETURN)
Filter	Propagate message to True terminal	Propagate message to False terminal	Propagate message to Unknown terminal	Deploy failure (BIP2912E: Type mismatch on RETURN)

User defined functions and procedures

When used in a function or a procedure, the RETURN statement stops processing of that function and returns control to the calling expression. The expression, which must be present if the function or procedure has been declared with a RETURNS clause, is evaluated and acts as the return value of the function. The data type of the returned value must be the same as that in the function's declaration. The following table describes the differences between the RETURN statement when used in user defined functions and procedures.

	RETURN expression;	RETURN NULL; (or return expression that evaluates to NULL)	RETURN;	No RETURN statement
User defined function or procedure with a RETURNS clause	Returns control to the calling expression with the value of expression	Returns control to the calling expression with NULL	Deploy failure (BIP2912E: Type mismatch on RETURN)	Returns control to the calling expression with NULL after all the statements in the function or procedure have been run
User defined function or procedure without a RETURNS clause	Deploy failure (BIP2401E: Syntax error: expected ; but found expression)	Deploy failure (BIP2401E: Syntax error: expected ; but found NULL)	Returns control to the calling expression	Returns control to the calling expression after all the statements in the function or procedure have been run

The RETURN statement must be used within the body of a function or procedure that has the RETURNS statement in its declaration. This function can be invoked using the CALL ... INTO statement. The RETURNS statement provides the datatype that the function or procedure returns to the CALL statement. The CALL ... INTO statement specifies the variable to which the return value is assigned. The example in this topic shows an example of how a RETURNS and CALL ... INTO statement are used together to assign the return statement. If you use the CALL ... INTO statement to call a function or procedure that does not have a RETURNS statement declared, a BIP2912E error message is generated.

Example

The following example, which is based on Example message, illustrates how the RETURN, RETURNS and CALL...INTO statements can be used:

CREATE FILTER MODULE ProcessOrder
 CREATE FUNCTION Main() RETURNS BOOLEAN  
  BEGIN  

      DECLARE SpecialOrder  BOOLEAN;
      SET  OutputRoot.MQMD = InputRoot.MQMD; 
      CALL IsBulkOrder(InputRoot.XMLNS.Invoice.Purchases) INTO SpecialOrder;
   
      --
      --  more processing could be inserted here
      --  before routing the order to the appropriate terminal
      -- 
      RETURN SpecialOrder;

  END;     

 CREATE FUNCTION IsBulkOrder (P1 REFERENCE)
        RETURNS BOOLEAN
  BEGIN 
      -- Declare and initialize variables--
      DECLARE a INT 1;
      DECLARE PriceTotal FLOAT 0.0;
      DECLARE NumItems INT 0;
      DECLARE iroot REFERENCE TO P1;

      -- Calculate value of order, however if this is a bulk purchase, the          --
      -- order will need to be handled differently (discount given) so return TRUE  --
      -- or FALSE depending on the size of the order                                --
      WHILE a <= CARDINALITY(iroot.Item[]) DO 
             SET  NumItems = NumItems + iroot.Item[a].Quantity;
             SET  PriceTotal = PriceTotal + iroot.Item[a].UnitPrice;
             SET  a = a + 1;
      END WHILE;
      RETURN (PriceTotal/NumItems> 42);

  END;

  END MODULE;

In the example, if the average price of items is greater than 42, TRUE is returned; otherwise FALSE is returned. Thus, a Filter node could route messages describing expensive items down a different path from messages describing inexpensive items. From the example, the

CALL IsBulkOrder(InputRoot.XMLNS.Invoice.Purchases)
INTO SpecialOrder;

statement can also be written as

SpecialOrder
= IsBulkOrder(InputRoot.XMLNS.Invoice.Purchases);

If you are using the PROPAGATE statement in your node it is important that you use a RETURN FALSE; to prevent automatic propagation of the message to the next node in the message flow. See PROPAGATE statement for an example of preventing the implicit propagate at the end of processing in a Compute node.