how to put/ collect an error message (custom) before raising the exception?

[former_member182350]

Hi Experts,

I am working on the checking the lead duplicacy by implementing of the BADI: <b>Order_save / check_before_save method which has the exception 'DO_NOT_SAVE'</b>.

My reqiurement is that how to <b>put/ collect an error message in the transaction error log or just throw</b> the mesage (custom) before<b> raising the exception??</b>

Can any body helps in this regard?? how and what r the FM/ ways to do this??

Thanks and Regards,,

Arjun,,,,

[Former Member]

Hi

Hope this helps you...

<b>Catchable Runtime Errors</b>

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-EXCEPTIONS using 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:

<b>CATCH SYSTEM-EXCEPTIONS <exc1> = <rc 1> ... <exc n> = <rc n>.

...

ENDCATCH.</b>

The expressions <exci> indicate either a catchable runtime error or the name of an exception group. The expressions <rc i> are numeric literals. If one of the specified runtime errors occurs between CATCH and ENDCATCH, the program does not terminate. Instead, the program jumps straight to the ENDCATCH statement. After ENDCATCH, the numeric literal <rc i> 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.

CATCH control structures are like IF structures, 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 defined 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. The ABAP keyword documentation contains an overview of the hierarchy of the defined exception classes.

With the predefined exception classes, a catchable runtime error between the TRY ... ENDTRY statements can be detected with the CATCH statement, 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.

___________________________________________________________________

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.

Regards,

Vara

[Former Member]

i am not entirely sure of your issue, but...

we use something like:

MESSAGE E100(YY)

RAISING MY_EXCEPTION

this raises the exception, and loads the message data into the SY- fields. in the calling program, if the SY_SUBRC <> 0, you can display the error message by using the SY-fields