topic Re: define our own Exceptions in th function builder in Application Development and Automation Discussions

define our own Exceptions in th function builder

Former Member — Mon, 25 Jun 2007 08:59:31 GMT

how to define our own Exceptions in th function builder in the Exception tab and how to use them in functon definiton.

regards

ravish

Re: define our own Exceptions in th function builder

Former Member — Mon, 25 Jun 2007 09:01:06 GMT

Refer

Re: define our own Exceptions in th function builder

Former Member — Mon, 25 Jun 2007 09:02:44 GMT

hi,

just define your exceptions in exceptions tab and call like this,

if sy-subrc eq 1.

raise ret_code." exception name

endif.

regards,

seshu.

Re: define our own Exceptions in th function builder

seshatalpasai_madala — Mon, 25 Jun 2007 09:03:27 GMT

Hi,

For any function module you can in transaction SE37 you can goto Exceptions tab and there you can type your Exception names.

From then on whenever you use CALL FUNCTION you will also have to use EXCEPTIONS to list the exception that this FM might raise.

Also there is an option of creating your own Exception class example classes that start with CX___________.

You can create exception classes ans using a check box in the SE37 you can make your FM raise class based exceptions instead of normal exceptions.

Regards,

Sesh

Re: define our own Exceptions in th function builder

Former Member — Mon, 25 Jun 2007 09:03:56 GMT

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.

Regards,

Padmam.

Re: define our own Exceptions in th function builder

Former Member — Mon, 25 Jun 2007 09:08:38 GMT

For eg:

If you have defined exceptions in the function module

based on sy-subrc value you can raise exceptionslike

Case sy-subrc.

when 1.

rasie < exception name1>.

when 2.

rasie < exception name2>.

when 3.

rasie < exception name3>.

when 4.

rasie < exception name4>.

....

endcase.

Regards

Raj