Exception class can be defined using to use static Text as well as the messages from the Message repository maintained using transaction SE91. In this article, lets see how to use the message from Message repository T100.
Define Exception Class using IF_T100_MESSAGE
To achieve and use the messages from the message repository, you need to include the interface
IF_T100_MESSAGE in the exception class. This interface allows you to declare and pass the message parameters when raising the exception.
As soon as you add the interface, the parameters of the method CONSTRUCTOR would be adjusted. The TEXTID field is not more referring to the field TEXTID. It would now refer to the type of the field
IF_T100_MESSAGE=>T100KEY. So, when you raise an exception, you can simply populate the fields of the key and they would be propagated back to the place where exception would be caught.
Interface IF_T100_MESSAGE has attribute T100KEY which would be available at time of catching the exception to retrieve the passed message id, message number and message parameters when exception was raised.
Exception ID in the Exception Class
For each Exception ID, in the Exception class, you can assign message class, message number and 4 attributes. To be able to assign one these 4 attributes, you would need to create a public attribute in the exception class. Once the attribute is available, you can select that instance attribute in the exception ID message text. E.g. As shown in the image, I have created an attribute IV_FIELD1 which as an attribute in the class which I have assigned to the attribute when I set the message text for the exception ID.
This text ID would be created as a Constant in the Exception Class as well.
Exception ID Constant
constants: begin of ZCX_MSG_T100, msgid type symsgid value '00', msgno type symsgno value '398', attr1 type scx_attrname value 'IV_FIELD1', attr2 type scx_attrname value ", attr3 type scx_attrname value ", attr4 type scx_attrname value ", end of ZCX_MSG_T100 .
The added public attribute, which you have used is also available as one of the parameter in the CONSTRUCTOR. This would let you assign a specific value to that attribute while raising the exception. Thus you can propagate that value
back the catcher of the exception.
Complete Public section of the Exception Class looks like this:
Exception Class Public section
class ZCX_MSG_T100 definition public inheriting from CX_NO_CHECK final create public . *"* public components of class ZCX_MSG_T100 *"* do not include other source files here!!! public section. interfaces IF_T100_MESSAGE . constants: begin of ZCX_MSG_T100, msgid type symsgid value '00', msgno type symsgno value '398', attr1 type scx_attrname value 'IV_FIELD1', attr2 type scx_attrname value ", attr3 type scx_attrname value ", attr4 type scx_attrname value ", end of ZCX_MSG_T100 . data IV_FIELD1 type CHAR10 . methods CONSTRUCTOR importing !TEXTID like IF_T100_MESSAGE=>T100KEY optional !PREVIOUS like PREVIOUS optional !IV_FIELD1 type CHAR10 optional .
Raising & Catching Exception
While raising the exception, you can provide all the parameters which are available in the CONSTRUCTOR method. This would than set proper attributes, which would be available at time of catching the exception. When proper parameters are set, it would provide proper information.
A small Demo to see it in action:
Program to Raise and Catch exception
*&---------------------------------------------------------------------* *& Purpose - Object Oriented Implementation for a Report *& Author - Naimesh Patel *& URL - http://zevolving.com/?p=2040 *&---------------------------------------------------------------------* REPORT ZTEST_NP_T100_EXCEPTION. * DATA: lo_exc TYPE REF TO zcx_msg_t100. DATA: ls_t100_key TYPE scx_t100key. * START-OF-SELECTION. * no message id, would take default ID * No additional parameter, message would be empty TRY. RAISE EXCEPTION TYPE zcx_msg_t100. CATCH zcx_msg_t100 INTO lo_exc. MESSAGE lo_exc TYPE 'I'. ENDTRY. * * Specific message ID, with parameter set TRY. RAISE EXCEPTION TYPE zcx_msg_t100 EXPORTING textid = zcx_msg_t100=>ZCX_MSG_T100 IV_FIELD1 = 'Value1'. CATCH zcx_msg_t100 INTO lo_exc. MESSAGE lo_exc TYPE 'I'. ENDTRY. * * Raising with a different message TRY. ls_t100_key-msgid = '00'. ls_t100_key-msgno = '443'. RAISE EXCEPTION TYPE zcx_msg_t100 EXPORTING textid = ls_t100_key. CATCH zcx_msg_t100 INTO lo_exc. MESSAGE lo_exc TYPE 'I'. * getting all the attributes of the message * like ID, class, attr1 etc MESSAGE ID lo_exc->IF_T100_MESSAGE~T100KEY-msgid TYPE 'I' NUMBER lo_exc->IF_T100_MESSAGE~T100KEY-msgno WITH lo_exc->IF_T100_MESSAGE~T100KEY-ATTR1. ENDTRY.
Multiple Exception IDs – Word of Caution
You would think this is great way to reduce the number of Exception Classes by creating many different exception IDs. When you have many exception IDs, they would need many different attributes. These attributes than would be added to CONSTRUCTOR. If you keep on adding various different attributes which are used in your Exception IDs, your Constructor method signature would grow. Over the time, it would be difficult for Other developers to know which fields are only needed when correctly raising the exception. Thus exception IDs should be logically grouped into Exception Classes.