exceptions

[Former Member]

hi gurus

what is the difference between catchable exceptions and non catchable exceptions?

[Former Member]

Hi,

Catchable exceptions are those, which you know could occur and you need to take care by writing the code within TRY..ENDTRY stmts.

For eg: divide by zero

Non-catchable exceptions that you do not expect, but happens due to some data error or coding error.

Regards,

Subramanian

[Former Member]

Hi,

There are actually three kinds of exceptions under CX_ROOT interface..

These vary depending on how to handle...

The following is the basic way to handle Exceptions.

The Syntax of TRY u2026u2026u2026 END TRY block is as follows.

TRY.
	{Code .............}
--------------------
--------------------
CATCH <exception class name> into <objref>.

	Text = objref->get_text( ).
---------------------
	---------------------

CLEANUP.
	--------------------
	--------------------
ENDTRY.

CATCH is a block where the occurred exception is caught and handled and if programmer wants to know the exception occurred then he/she is supposed to give a message of that exception.

The statement u201CText = objref->get_text( )u201D specified in the above syntax is to capture the text of that exception occurred.

The user can get the u2018Textu2019 by using get_text( ) method of CX_ROOT interface (IF_MESSAGE~GET_TEXT).

GET_TEXT: Returns a text description of the exception.

Sends back the exception texts of a class (controlled by the TEXTID attribute) as a string.

So the exceptions can be handled in the current TRY block itself or can also be propagated using the RAISE EXCEPTION... statement.

RAISE EXCEPTION TYPE < CX_..... >.

In SAP the exceptions are prefixed by u2019CX_u2019 and classes as u2019CL_u2019.

CLEANUP Block is executed if TRY-ENDTRY block is exited because the system cannot find a handler for an exception within a specific TRY-ENDTRY block but the exception is handled in a surrounding TRY-ENDRY block or propagated to a calling program.

CX_ROOT is a root interface of all exceptions.

These are subclasses under CX_ROOT --> CX_STATIC_CHECK , CX_DYNAMIC_CHECK, and CX_NO_CHECK.

CX_STATIC_CHECK:

The class CX_STATIC_CHECK classifies exceptions whose handling is checked by the compiler. If an exception of this category could occur, it must either be handled (using TRY...CATCH) or passed along (using RAISING). At runtime, exceptions of this type only leave the procedure interface if they are declared in the procedure's RAISING clause.

CX_DYNAMIC_CHECK:

The class CX_DYNAMIC_CHECK classifies exceptions that are not to be checked statically by the compiler. However, these exceptions can be declared in the RAISING clause of a procedure. If they are, then the exception can pass the procedure interface at runtime, if it has not already been handled locally. At runtime, these exceptions behave in the same way as exceptions in the CX_STATIC_CHECK category, except that they are checked by the compiler at compile-time. These exceptions are particularly well-suited to displaying interface violations. No syntax warning is reported if the exception is neither handled nor propagated. If the exception is then raised, a runtime error occurs.

Typical examples of this situation are predefined exceptions CX_SY_... for errors that occur in the runtime environment. These are usually subclass of CX_DYNAMIC_CHECK

(CX_SY_ARITHMETIC_ERROR , CX_SY_MOVE_CAST_ERROR).

CX_NO_CHECK:

The class CX_NO_CHECK classifies exceptions that are not checked for consistency, either statically by the compiler or dynamically at runtime. Logically, these exceptions cannot be declared in the RAISING clause of a procedure. An exception in this category is always passed along the call hierarchy, until an appropriate handler is found, or - if there is no appropriate handler - a runtime error occurs. These exceptions are particularly well-suited to displaying resource bottlenecks (which can occur in many different places, but which few developers want to deal with).

Hope the information provided would be clear enough to you.

Any queries REVERT back.

Regards

Narin Nandivada

[Former Member]

Hi,

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.

Catchable Exceptions

CX_SY_CREATE_OBJECT_ERROR

Cause: System tried to instantiate an abstract class.

Runtime Error: CREATE_OBJECT_CLASS_ABSTRACT (catchable)

Cause: Cannot find the class declared in the TYPE addition.

Runtime Error: CREATE_OBJECT_CLASS_NOT_FOUND (catchable)

Cause: System tried to instantiate a private class from outside the class itself.

Runtime Error: CREATE_OBJECT_CREATE_PRIVATE (catchable)

Cause: System tried to instantiate a protected class from outside the class itself.

Runtime Error: CREATE_OBJECT_CREATE_PROTECTED (catchable)

http://help.sap.com/saphelp_nw70/helpdata/en/cf/f2bbce142c11d3b93a0000e8353423/content.htm

Non-Catchable Exceptions

Cause: You must declare a reference as a target variable.

Runtime Error: CREATE_OBJECT_NO_REFTYPE

Regards,

Sujit

[Former Member]

Hi Diana,

Plz refer to the link below:

http://help.sap.com/saphelp_nw70/helpdata/en/cf/f2bbce142c11d3b93a0000e8353423/content.htm

With luck,

Pritam.