regarding function

[Former Member]

Dear Abapers,

I have one doubt about function modules.

while calling function modules in function modules if there is exceptions

how to handle exceptions .I have given one example below.

after exception sy-subrc will come with function module if we put that code is it ok.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

• DDIC_STRUCTURE = ' '

retfield =

• PVALKEY = ' '

• DYNPPROG = ' '

• DYNPNR = ' '

• DYNPROFIELD = ' '

• STEPL = 0

• WINDOW_TITLE =

• VALUE = ' '

• VALUE_ORG = 'C'

• MULTIPLE_CHOICE = ' '

• DISPLAY = ' '

• CALLBACK_PROGRAM = ' '

• CALLBACK_FORM = ' '

• MARK_TAB =

• IMPORTING

• USER_RESET =

tables

value_tab =

• FIELD_TAB =

• RETURN_TAB =

• DYNPFLD_MAPPING =

EXCEPTIONS

PARAMETER_ERROR = 1

NO_VALUES_FOUND = 2

OTHERS = 3

.

IF sy-subrc <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

[Former Member]

Hi,

This is correct.

After checking the sy-subrc you can give proper error message based on the exception.

For example.

If sy-subrc = 1.

Display message like "Parameter error"

elseIf sy-subrc = 2.

Display message like "No values found"

elseIf sy-subrc = 3.

Display message like "Other error"

endif.

Reward if helpful.

[Former Member]

Dear Uma shanker and Kishore,

Thanks for replying me.

this block of statement will come with function module is it ok. but I have writtern in

messge id in Report statement(Report <report-name >) message-id <messge-name>.

IF sy-subrc <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

OR

we have to write explicitely like:-

If sy-subrc = 1.

Display message like "Parameter error"

elseIf sy-subrc = 2.

Display message like "No values found"

elseIf sy-subrc = 3.

Display message like "Other error"

endif.

[Former Member]

hi,

All you need to do is have the EXCEPTIONS section uncomment, then simply write out a message depending on the Sy-SUBRC value .

Call function 'Z_TEST_FUNCTION'.

Exceptions

not_found = 1

not_valid = 2

you_are_crazy = 3

you_are_completely_nuts = 4.

case sy-subrc .

when '1'.

write:/ 'Not Found'.

when '2'.

write:/ 'Not Valid''.

when '3'.

write:/ 'You Are Crazy'.

when '4'.

write:/ 'You Are Completely Nuts'.

endcase.

Regards,

Kishi.

[Former Member]

Hi,

we can do like this.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

• DDIC_STRUCTURE = ' '

retfield =

• PVALKEY = ' '

• DYNPPROG = ' '

• DYNPNR = ' '

• DYNPROFIELD = ' '

• STEPL = 0

• WINDOW_TITLE =

• VALUE = ' '

• VALUE_ORG = 'C'

• MULTIPLE_CHOICE = ' '

• DISPLAY = ' '

• CALLBACK_PROGRAM = ' '

• CALLBACK_FORM = ' '

• MARK_TAB =

• IMPORTING

• USER_RESET =

tables

value_tab =

• FIELD_TAB =

• RETURN_TAB =

• DYNPFLD_MAPPING =

EXCEPTIONS

PARAMETER_ERROR = 1

NO_VALUES_FOUND = 2

OTHERS = 3

.

<b>IF sy-subrc <> 0.

write:/ 'problem while calling function module.'.

ENDIF. </b>

rgds,

bharat.

[Former Member]

Hi

Exceptions

The exception of a function module are defined on the Exceptions tab page in the Function Builder. Here you can select exception classes to define whether class-based exceptions are declared or non-class-based exception are defined. Class-based exceptions are represented in the above syntax by RAISING, and non-class-based exceptions are represented by EXCEPTIONS.

The addition RAISING is used to declare class-based exceptions that can be propagated from the function module to the caller. Exceptions in the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be explicitly declared, otherwise a propagation can lead to an interface violation. A violation of the interface leads to the treatable exception CX_SY_NO_HANDLER. Exceptions of the category CX_NO_CHECK are implicitly always declared. The declaration of exceptions of the category CX_STATIC_CHECK is statically checked in the syntax check. For exceptions of the category CX_DYNAMIC_CHECK, the check is not performed until runtime. In a function module in which class-based exceptions are declared with the RAISING addition, the statement CATCH SYSTEM-EXCEPTIONS cannot be used. Instead, the relevant treatable exceptions should be handled in a TRY control structure.

The addition EXCEPTIONS is used to define a list of non-class-based exceptions that can be triggered in the function module using the statements RAISE or MESSAGE RAISING. Exceptions defined in this way - as with formal parameters - are bound to the function module and cannot be propagated. If an exception of this type is triggered in a function module, and no return value has been assigned to it with the homonymous addition EXCEPTIONS of the CALL FUNCTION statement when the call was made, this leads to a runtime error.

Note

For new developments after release 6.10, SAP recommends that you work with class-based exceptions that are independent of the function module.

Reward points for useful Answers

Regards

Anji