FM

[Former Member]

how to handle expections in FM and

what are the errors in FM

[Former Member]

Hi sripathi,

chk this:

http://help.sap.com/saphelp_nw2004s/helpdata/en/9f/db96ef35c111d1829f0000e829fbfe/content.htm

chk this example for exception handling:

REPORT demo_mod_tech_fb_string_split.

DATA: text(10) TYPE c VALUE '0123456789',

text1(6) TYPE c,

text2(6) TYPE c.

PARAMETERS position TYPE i.

CALL FUNCTION 'STRING_SPLIT_AT_POSITION'

EXPORTING

string = text

pos = position

IMPORTING

string1 = text1

string2 = text2

EXCEPTIONS

string1_too_small = 1

string2_too_small = 2

pos_not_valid = 3

OTHERS = 4.

CASE sy-subrc.

WHEN 0.

WRITE: / text, / text1, / text2.

WHEN 1.

WRITE 'Target field 1 too short!'.

WHEN 2.

WRITE 'Target field 2 too short!'.

WHEN 3.

WRITE 'Invalid split position!'.

WHEN 4.

WRITE 'Other errors!'.

ENDCASE.

The function module splits an input field into two output fields at a specified position. If the content of position is in the interval [4,6], the function module is executed without any exceptions being raised. For the intervals [1,3] and [7,9], the system triggers the exceptions string1_too_small and string2_too_small respectively. For all other values of position, the exception pos_not_valid is triggered.

regards,

keerthi

Message was edited by:

keerthi kiran varanasi

[Former Member]

Catchable Runtime Errors

Error situations in the runtime environment that were handled in the program were handled as catchable runtime errors up to Release 6.10. Catachable runtime errors are assigned to certain ABAP statements and are triggered by the runtime environment if errors are detected in an ABAP statement.

Catchable runtime errors are handled with CATCH SYSTEM-EXCEPTIONSusing the name of the runtime error. To detect semantically related runtime errors using a common name, they are combined into exception groups.

You can handle catchable runtime errors in an ABAP program using the following control statements:

CATCH SYSTEM-EXCEPTIONS exc1 = rc1 ... excn = rcn.

...

ENDCATCH.

The expressions exc1 … excn indicate either a catchable runtime error or the name of an exception class. The expressions rc1 … rcn are numeric literals. If one of the specified runtime errors occurs betweenCATCHand ENDCATCH, the program does not terminate. Instead, the program jumps straight to the ENDCATCH statement. After ENDCATCH, the numeric literal rc1 … rcn that you assigned to the runtime error is contained in the return code field SY-SUBRC. The contents of any fields that occur in the statement in which the error occurred cannot be guaranteed after ENDCATCH.

CATCH control structures are like IFstructures, that is, you can nest them to any depth, but they must begin and end within the same processing block. Furthermore, CATCH control structures only catch runtime errors at the current call level, and not in any procedures that you call from within the CATCH … ENDCATCH block.

Since as of Release 6.10 exceptions are generally handled based on classes, each detectable runtime error is assigned to a predefined exception class. The exception groups were assigned to abstract intermediate classes in the inheritance hierarchy of the assigned exception classes. The defined exception classes adhere to the naming convention CX_SY_ ..., for example CX_SY_ZERODIVIDE. For an overview of the hierarchy of the predefined exception classes, use the ABAP keyword documentation.

With the predefined exception classes, a catchable runtime error between the TRY ... ENDTRY statements can be detected with the CATCHstatement, like all exceptions that can be handled. This is the preferred method. Parallel handling with TRY ... ENDTRY and CATCH ... ENDCATCH is not allowed within a processing block. No new catchable runtime errors are planned for the future. Instead, it is exceptions in ABAP statements will only be handled by assigning exception classes.

REPORT demo_catch_endcatch.

DATA: result TYPE p DECIMALS 3,

number TYPE i VALUE 11.

CATCH SYSTEM-EXCEPTIONS arithmetic_errors = 5.

DO.

number = number - 1.

result = 1 / number.

WRITE: / number, result.

ENDDO.

ENDCATCH.

SKIP.

IF sy-subrc = 5.

WRITE / 'Division by zero!'.

ENDIF.

The program calculates the quotients tens time from 1 and number until the runtime error BCD_ZERODIVIDE occurs. This belongs to the exception group ARITHMETIC_ERRORS, and is caught in the example using this class.

regards

navjot

reward points if helpfull

[Former Member]

You can handle exceptions for function modules in the following way. Say that you wanted to do something different for each exception. [code]CALL FUNCTION 'BDC_CLOSE_GROUP'

EXCEPTIONS

NOT_OPEN = 1

QUEUE_ERROR = 2

OTHERS = 3

.

case sy-subrc.

When '1'.

Write:/ 'not open'.

when '2'.

write:/ 'queue error'.

when '3'.

write:/ 'others'.

endcase.

regards

navjot

give points if helpfull

Message was edited by:

navjot sharma

[Former Member]

Message Handling in Function Module Modules

Contexts are obsolete and should not be used. Contexts were introduced for Release 4.0 for high performance access to frequently required data. Since the introduction of ABAP Objects for Release 4.5, contexts have not been developed further. Since Release 6.40, contexts can be replaced by shared objects.

In order for a message to be sent from a function module context module, the function module must contain the necessary exception handling. Exception handling in the function module must be programmed with the statement MESSAGE... RAISING. If exception handling in the function module is programmed using the RAISE statement, the system reacts with a runtime error. For more information about exception handling in function modules, see Function Modules.

The system sends the message specified in the MESSAGE... RAISING statement. Messages specified for function modules in the Modules table are ignored.

When you query dependent data from context instances using the DEMANDstatement, you can decide whether the system should handle the user message or whether you want to handle it yourself in the program.

Message Handling - System

If you want the system to handle the message, use the basic form of the DEMAND statement without the MESSAGES option. The system will then behave as though the MESSAGE statement in the function module occurred after the DEMAND statement. Note that the system reaction to the various message types depends on the current user dialog (dialog screen, selection screen, or list).

Message Handling - Program

If you want to catch the message in your program, use the DEMANDstatement with the option MESSAGES INTO itab. To do this, you need to define an internal table itab with the structure SYMSG. The system deletes the contents of the itab table at the beginning of the DEMANDstatement. Whilst it is processing the context, the system does not output or react to any messages, but writes their ID to itab. If there are messages in the table following the DEMANDstatement, the system sets the return code sy-subrc to a value unequal to zero.

This enables you to prevent automatic message handling with contexts and allows you to program your own using the entries in <itab>. This is important, for example, if you want to make particular fields on an entry screen ready for input again. In this case, you must base your message handling on these fields (using the FIELDS statement in the screen flow logic, or the ABAP statement AT SELECTION-SCREEN for selection screens), and not on fields in the context.

The function module percent has the following source code:

FUNCTION percent.

result = v1 - v2.

IF v1 = 0.

MESSAGE ID 'AT' TYPE 'E' NUMBER '012' RAISING div_zero.

ELSE.

result = result * 100 / v1.

ENDIF.

ENDFUNCTION.

Context docu_test4 uses this function module as its only module, with key fields max and occ for input parameters v1 and v2 and the dependent field percent for the output parameter result.

To demonstrate system message handling, execute the following program:

REPORT demo_context_message_3.

DATA percentage TYPE i.

CONTEXTS docu_test4.

DATA: context_inst TYPE context_docu_test4.

SUPPLY max = 00

occ = 20

TO CONTEXT context_inst.

DEMAND percent = percentage

FROM CONTEXT context_inst.

WRITE: / 'Percentage: ', percentage.

The program terminates with the following error message:

This is an error message

To demonstrate program message handling, execute the following program:

REPORT demo_context_message_4.

DATA: percentage TYPE i.

CONTEXTS docu_test4.

DATA: context_inst TYPE context_docu_test4.

DATA itab TYPE TABLE OF symsg WITH HEADER LINE.

SUPPLY max = 00

occ = 20

TO CONTEXT context_inst.

DEMAND percent = percentage

FROM CONTEXT context_inst MESSAGES INTO itab.

WRITE: / 'Percentage: ', percentage. "#EC NOTEXT

IF sy-subrc NE 0.

LOOP AT itab.

WRITE: / itab-msgty, / itab-msgid, / itab-msgno,

/ itab-msgv1, / itab-msgv2.

ENDLOOP.

ENDIF.

The program outputs the following:

PERCENTAGE: 0

E AT 012

Instead of terminating with an error message, the program stores the message in the internal table itab, where it is available for you to process further.

[Former Member]

Hi Sripathi,

Check this info.

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.

Hope this resolves your query.

Reward all the helpful answers.

Regards