Catch a DBIF_RSQL_SQL_ERROR Exception

[Former Member]

Hi,

Anyone knows how to catch the exception DBIF_RSQL_SQL_ERROR ? We are on 4.6C and it seems that I'm not allowed to use TRY CATCH ENDTRY statement in 4.6C (Invalid statement 'try'). I've searching for CATCH SYSTEM-EXCEPTIONS , but the DBIF_RSQL_SQL_ERROR is not in System Exceptions List.

Sometimes this exceptions occurs because I'm accessing a DBlink Table alias, that's the reason I have to know when the exceptions occurs to send data to a Z Error Table.

thanks,

Rodrigo

[Former Member]

DBIF_RSQL_SQL_ERROR is a system generated error. U can catch the error in ur program. this error occurs whenever database access exceeds some limit & the error is fired.

[Former Member]

Ok, and how can I catch this exception in my program ? Do you have any sample code ?

thanks

Rodrigo Glauser

[Former Member]

I, too, would love to know how to catch this error. To my knowledge, it is not trappable.

I believe the dump to be quite intentional to prevent corrupted/erroneous data from hitting the DB.

You should review ST22 and analyze the error. This should point you to the DB issue... frequently a table space issue.

[Former Member]

Handling Exceptions

The occurrence of an exception is normally used to display an error situation. The handler of an exception must try to correct the error that has occurred, find an alternative solution, or (if this is not possible) at least bring the affected context into a consistent state and then forward the error. If a call hierarchy does not contain a handler for an exception, the program is ended with a runtime error. Since exceptions cannot be handled by means of program calls, all possible exceptions within the program itself must be handled to prevent a runtime error. This rule does not apply to the coding within procedures whose exceptions can easily be propagated to (external) callers.

Class-based exceptions are handled in the following control structure:

TRY.

... " TRY block (application coding)

CATCH cx_... cx_... ...

... " CATCH block (exception handler)

CATCH cx_... cx_... ...

... " CATCH block (exception handler)

...

CLEANUP.

... " CLEANUP block (cleanup context)

ENDTRY.

The TRY statement opens a control structure to be ended with ENDTRY, in which three statement blocks can be listed in a specified order (this is not obligatory).

A TRY block, in which exceptions can occur.

This exception block consists of all the statements between the TRY and the CATCH statement.

One or more CATCH blocks for catching exceptions.

These exception blocks are initiated with CATCH and ended with a further CATCH, CLEANUP, or ENDTRY.

A CLEANUP block for cleanup work after the exceptions have been caught.

This statement block is initiated by CLEANUP and ended with ENDTRY. A TRY-ENDTRY structure must not contain more than one CLEANUP block in precisely this position.

Like all ABAP control structures, TRY-ENDTRY structures can be nested in any statement blocks (see Controlling the Program Flow). In particular, the three statements blocks above can also contain complete TRY-ENDTRY blocks. Like all ABAP control structures, each TRY-ENDTRY structure must be contained fully in a processing block (event block, dialog module, procedure). This means that the application coding of a TRY-ENDTRY structure cannot include several processing blocks.

TRY Block

The TRY block contains the application coding whose exceptions are to be handled. This statement block is processed sequentially. It can contain further control structures and calls of procedures or other ABAP programs.

If an exception occurs in the TRY block or in a procedure called up here, the system starts by searching for a CATCH statement of the same TRY-ENDTRY structure. It then searches from the inside out for a CATCH statement in any enclosing TRY-ENDTRY structures that handle the event. The system may call this handler. If the system does not find a handler, but the TRY-ENDTRY structure is contained in a procedure, it tries to propagate the exception to the caller (see also Propagating Exceptions). Exceptions cannot be propagated in any processing blocks without a local data area (event blocks, dialog modules). A runtime error occurs immediately if the handler is missing.

If no exceptions occur in the TRY block, program execution is continued directly after ENDTRY after the block has been completed.

CATCH Block

A catch block contains the exception handler that is executed when a particular exception has occurred in the TRY block of the same TRY-ENDTRY structure. A TRY-ENDTRY structure can contain several exception handlers. The syntax for introducing an exception handler is:

CATCH cx_... cx_... INTO ref.

Any number of exception classes can be specified after CATCH. This defines an exception handler for all the specified exception classes and their subordinate classes.

After an exception occurs, the system searches through the listed exception handlers in the specified order. The first exception handler whose CATCH statement contains the corresponding exception class or one of its superclasses is executed. The system then continues program execution directly after ENDTRY. No subsequent exception handlers are considered. For this reason, the order of the different exception handlers within a TRY-ENDTRY structure must be based on the inheritance hierarchy of the specified exception classes.

The syntax check ensures that the handlers for more specific exceptions (subordinate classes) can only be listed before the handlers for more general exceptions (superclasses). For example, a handler for the most general exception class CX_ROOT can only ever be the last statement block before CLEANUP or ENTRY. Otherwise, none of the subsequent handlers would ever be reached.

With the INTO addition, a reference to the exception object can be placed a reference variable. This enables the attributes of the exception object to be accessed in the handler. The reference variable must be suitable for the exception. Its static type must be the exception class itself or one of its superclasses. You are advised to use an exception class below CX_ROOT or CX_ROOT itself rather than the general class OBJECT. Only these classes contain the methods relevant for exceptions.

CLEANUP Block

If the system does not find a handler for an exception in a TRY-ENDTRY structure, it searches for a handler in the enclosing TRY-ENDTRY structures from the inside out (as mentioned above). If the system does not find a handler here, it tries to propagate the exception to a procedure caller.

Precisely one CLEANUP block can be defined in each TRY-ENDTRY structure. If the system has not found a handler for an exception, but the exception is handled in an enclosing TRY-ENDTRY structure or is propagated to a caller, the block is executed before the TRY-ENDTRY structure is exited.

In the CLEANUP block, cleanup work can be executed for the context of the TRY block. For example, objects often have to be brought into a consistent state or external resources, to which an external handler no longer has access, have to be released. The nesting of TRY-ENDTRY blocks and the possible propagation of exceptions may mean that several CLEANUP blocks are executed before an exception is actually handled.

Since the only purpose of the CLEANUP block is to restore the consistency of a context, it can only be exited in the normal way, in other words, once its last statement is reached. For this reason, all the statements that change the control flow, which cause the CLEANUP block to be exited and would initiate a processing block of the same program, are forbidden. This applies to statements such as RETURN, STOP, for example. For the same reason, all the exceptions that occur within a CLEANUP block must also be handled here. It is, however, permissible to leave the overall program (LEAVE PROGRAM) or call up procedures, programs, and screen sequences if the system returns to the CLEANUP block. The runtime environment always recognizes that a CLEANUP block is being exited illegally and then reacts with a runtime error.

Example

report DEMO_HANDLE_EXCEPTIONS.

parameters NUMBER type I.

data RESULT type P decimals 2.

data OREF type ref to CX_ROOT.

data TEXT type STRING.

start-of-selection.

write: / 'Testing division and Sqare root with', NUMBER.

uline.

try.

if ABS( NUMBER ) > 100.

raise exception type CX_DEMO_ABS_TOO_LARGE.

endif.

try.

RESULT = 1 / NUMBER.

write: / 'Result of division:', RESULT.

RESULT = SQRT( NUMBER ).

write: / 'Result of square root:', RESULT.

catch CX_SY_ZERODIVIDE into OREF.

TEXT = OREF->GET_TEXT( ).

cleanup.

clear RESULT.

endtry.

catch CX_SY_ARITHMETIC_ERROR into OREF.

TEXT = OREF->GET_TEXT( ).

catch CX_ROOT into OREF.

TEXT = OREF->GET_TEXT( ).

endtry.

if not TEXT is initial.

write / TEXT.

endif.

write: / 'Final result:', RESULT.

In this example, a TRY-ENDTRY structure is nested in the TRY block of a different TRY-ENDTRY structure. The following four scenarios are demonstrated in the example:

Catching an Exception by Handling a Superclass

If NUMBER is greater than 100, the exception CX_DEMO_ABS_TOO_LARGE that is self-defined in the Exception Builder of the ABAP Workbench is raised in the TRY block of the external TRY-ENDTRY structure. This exception is the subordinate class of the most general exception, CX_ROOT, and is handled by the second CATCH block of the same TRY-ENDTRY structure.

Catching an Exception by Handling the Suitable Class

If NUMBER is equal to zero, the exception CX_SY_ZERODIVIDE predefined in the system is raised as a result of the division in the TRY block of the internal TRY-ENDTRY structure and handled in the corresponding CATCH block of the same TRY-ENDTRY structure.

Executing a CLEANUP Block Before Catching an Exception

If NUMBER is a negative number, the exception CX_SY_ARG_OUT_OF_DOMAIN predefined in the system is raised in the TRY block of the internal TRY-ENDTRY structure using the SQRT function. Since a handler is not defined for this exception in the internal TRY-ENDTRY structure but is defined in the external TRY-ENDTRY structure, the CLEANUP block of the internal TRY-ENDTRY structure is executed. The exception is then handled in the first CATCH block of the external TRY-ENDTRY structure, since CX_SY_ARG_OUT_OF_DOMAIN is the subordinate class of CX_SY_ARITHMETIC_ERROR.

No Exception

In all other cases, an exception is not raised and the TRY blocks of both TRY-ENDTRY structures are fully processed.

In all CATCH statements in the example, the object references to the corresponding exception objects are stored in the OREF reference variable. Using OREF, the individual handlers access the exception texts of the individual exception objects and store them in the TEXT string variable.

[Former Member]

Defining Exceptions

Exceptions are represented by objects that are instances of exception classes. Defining an exception is, therefore, the same as creating an exception class.

All exception classes must inherit from the common superclass CX_ROOT and one of its subordinate classes:

CX_STATIC_CHECK

CX_DYNAMIC_CHECK

CX_NO_CHECK

. The assignment of exception classes to one of these three paths of the inheritance hierarchy determines the way in which the associated exceptions are propagated. There is a record of predefined exception classes CX_SY_... whose exceptions are raised in error situations in the runtime environment. These classes all inherit from CX_DYNAMIC_CHECK or CX_NO_CHECK but not from CX_STATIC_CHECK (see hierarchy in the ABAP keyword documentation).

All exception classes must begin with the prefix CX_. They are usually defined globally with the Class Builder of the ABAP Workbench. Local exception classes can, however, also be defined.

Individual (abstract) exception classes that are used as the superclass of further exception classes can be defined. The exceptions of the subordinate classes can be handled together using a superclass.

Exception classes have the following features:

Constructor

The constructor must have a predefined structure and a specific interface. With global classes, the Class Builder generates the correct constructor and sets it to an unchangeable status. The constructor has two IMPORTING parameters:

TEXTID of the SOTR_CONC type

This parameter can be used to determine which of your exception texts the exception will use.

PREVIOUS of the CX_ROOT type

This parameter can be used to assign the PREVIOUS attribute a previous exception.

Methods

In exception classes, you can define your own methods. The following two predefined methods are inherited from the root class CX_ROOT:

GET_TEXT

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

GET_SOURCE_POSITION

Returns the program name, the name of a possible include program, and the line number of the statement that raised the exception.

Attributes

The attributes of exception classes are used to transport additional information on an error situation to the handler. The main piece of information is, however, always the fact that an exception of a particular class has occurred. The following attributes are inherited from CX_ROOT:

TEXTID

Used to specify the exception of a class more precisely by using several exception texts. Is evaluated in the GET_TEXT method.

PREVIOUS

If an exception is mapped to another exception, a reference to the original exception can be defined in this attribute via the EXPORTING addition of the RAISE EXCEPTION statement and by means of the constructor IMPORTING PARAMETER with the same name. This can result in a chain of exception objects. In the event of a runtime error, the exception texts of all the exceptions in the chain are output. Mapping an exception to another exception is only beneficial if the context in which the original exception occurred is important for characterizing the error situation.

KERNEL_ERRID

The name of the associated runtime error is stored in this attribute if the exception was raised by the runtime environment, for example, COMPUTE_INT_ZERODIVIDE with a division by zero. If the exception is not handled, precisely this runtime error occurs.

Parameters cannot be transferred to the constructor for this attribute. If the exception is raised with RAISE EXCEPTION, the attribute is set to initial.

Global Exception Classes

Global exception classes are defined and managed in the Class Builder. If the correct naming convention (prefix CX_) and the class type Exception Class is chosen when a new class is created, the Class Builder automatically becomes the Exception Builder.

The Exception Builder offers precisely the functionality required to define exception classes and generates independently-defined components that must not be changed. When classes are created, the category of the exception must be specified, in other words, whether it is to inherit from CX_STATIC_CHECK, CX_DYNAMIC_CHECK, or CX_NOCHECK.

Tab Pages of the Exception Builder

The Exception Builder has the tab pages Properties, Attributes, Methods, and Texts.

The properties do not normally need to be changed.

Except for the four inherited attributes mentioned above, further public attributes can be generated by the Exception Builder. The contents of these attributes specify the exception more clearly and manage the exception texts.

All of the methods are inherited from CX_ROOT. New methods cannot be added. The instance constructor is generated automatically. It ensures that, when an exception is raised, the attributes have the right values. It also transfers the text of the superclass for an exception class whose exception text is not specified explicitly.

The instance constructor is generated on the basis of the attributes, which are set up on the basis of the exception texts. Changing the attributes in superclasses can, therefore, invalidate the constructors of subordinate classes. The constructors of subordinate classes can be regenerated under Utilities ® CleanUp ® Constructor.

Texts are a special feature of exception classes and the Exception Builder. For further information, refer to Exception Texts.

Local Exception Classes

Local exception classes can be defined for specific exceptions that only occur within one single ABAP program. The condition for a local exception class is that it inherits from one of the three classes CX_STATIC_CHECK, CX_DYNAMIC_CHECK, or CX_NO_CHECK, or from their subordinate classes. An individual constructor and individual attributes can be created. Individual methods should not be created, however, and the methods of superclasses should not be redefined.

Examples of Local Exception Classes

report DEMO_LOCAL_EXCEPTION_1.

class CX_LOCAL_EXCEPTION definition

inheriting from CX_STATIC_CHECK.

endclass.

start-of-selection.

try.

raise exception type CX_LOCAL_EXCEPTION.

catch CX_LOCAL_EXCEPTION.

message 'Local Exception!' type 'I'.

endtry.

This example shows a minimal local exception class, which is simply the local representation of one of the three direct subordinate classes of CX_ROOT. It can be used in the program.

report DEMO_LOCAL_EXCEPTION_2.

class CX_LOCAL_EXCEPTION definition

inheriting from CX_STATIC_CHECK.

public section.

data LOCAL_TEXT type STRING.

methods CONSTRUCTOR importing TEXT type STRING.

endclass.

class CX_LOCAL_EXCEPTION implementation.

method CONSTRUCTOR.

SUPER->CONSTRUCTOR( ).

LOCAL_TEXT = TEXT.

endmethod.

endclass.

data OREF type ref to CX_LOCAL_EXCEPTION.

start-of-selection.

try.

raise exception type CX_LOCAL_EXCEPTION

exporting TEXT = `Local Exception`.

catch CX_LOCAL_EXCEPTION into OREF.

message OREF->LOCAL_TEXT type 'I'.

endtry.

In this example, the exception class from the previous example is extended to include an individual attribute and constructor. The IMPORTING parameter of the constructor must be supplied when the exception is raised (it is required here). The attribute can be evaluated in the handler of the exception.

report DEMO_LOCAL_EXCEPTION_3.

class CX_LOCAL_EXCEPTION definition

inheriting from CX_SY_ARITHMETIC_ERROR.

public section.

methods CONSTRUCTOR importing SITUATION type STRING.

endclass.

class CX_LOCAL_EXCEPTION implementation.

method CONSTRUCTOR.

SUPER->CONSTRUCTOR( OPERATION = SITUATION ).

endmethod.

endclass.

data OREF type ref to CX_LOCAL_EXCEPTION.

data TEXT type STRING.

start-of-selection.

try.

raise exception type CX_LOCAL_EXCEPTION

exporting SITUATION = `START-OF-SELECTION`.

catch CX_LOCAL_EXCEPTION into OREF.

TEXT = OREF->GET_TEXT( ).

message TEXT type 'I'.

endtry.

In this example, an exception class is derived from one of the predefined exception classes for error situations in the runtime environment. An individual constructor is defined with an individual IMPORTING parameter that supplies the superclass constructor with this parameter. When the exception is handled, the exception text, as defined in the superclass, is read with GET_TEXT.