Mensajes en ABAP-Especificación de mensaje implícito en RAISE EXCEPTION

En una introducción a los mensajes en ABAP publicación de blog, ya expliqué los conceptos básicos de los conceptos de mensajería. Aquí, me gustaría continuar con la evolución de la mensajería en ABAP a la nueva forma. A partir de la versión 7.52, la nueva forma abreviada USO DE MENSAJE de la declaración RAISE EXCEPTION con la adición de MENSAJE hace posible pasar el contenido de los campos del sistema implícitamente a las excepciones de las clases de excepción que incluyen la interfaz del sistema IF_T100_DYN_MSG.

Para empezar, déjame darte un resumen rápido de cuáles son las excepciones y la forma en que podemos manejarlas.

Mensajes son textos que se crean utilizando un mensaje de actualización (transacción SE91). Se almacenan en la tabla del sistema T100.ISe exigió asociar objetos con mensajes y mostrarlos usando la declaración MENSAJE. Esto estaba pensado principalmente para textos de excepción de clases de excepción.

Las excepciones son eventos durante la ejecución de un programa ABAP que interrumpen el flujo del programa porque no es posible que el programa continúe de manera significativa. Estos eventos son atrapables o no atrapables. Las excepciones no detectables son generadas solo por el marco de tiempo de ejecución ABAP y producen un error de tiempo de ejecución, que ya discutí en otro entrada en el blog. Las excepciones capturables son basado en clases y puede manejarse entre la estructura de control TRY y ENDTRY. El INTENTAR bloque define un área protegida cuyas excepciones se pueden manejar en posteriores ATRAPAR bloques Un bloque CATCH maneja las excepciones de las clases de excepción cx_class1 cx_class2… que se especifican después de la declaración CATCH, así como las excepciones de las subclases de estas clases de excepción.

Las clases de excepción están predefinidas globalmente en el sistema o pueden ser definidas por el usuario tanto global como localmente. Hay dos opciones para generar excepciones basadas en clases.

• Levantamiento controlado por el sistema en el entorno de tiempo de ejecución
• Programa de crianza en el programa ABAP

El asociado clases de excepción que están predefinidos en el sistema, comienzan con el prefijo CX_SY_, como CX_SY_ZERODIVIDE. En el Documentación de palabras clave ABAPlas clases de excepción cuyas excepciones pueden ocurrir cuando se ejecuta una instrucción ABAP correspondiente se enumeran para cada palabra clave.

Antes de que se introdujeran las clases de excepción, se podía manejar el mensaje de error en un módulo de funciones como una excepción con texto a través de la excepción general ‘error_message’. Estas excepciones no basadas en clases también se pueden manejar en módulos de funciones, así como en definiciones de clases, definiendo una excepción y ‘aumentándola’.

Más tarde, se exigió asociar objetos con mensajes y mostrarlos usando la declaración MENSAJE. Esto estaba pensado principalmente para textos de excepción de clases de excepción. A medida que se define el concepto de clase de excepción, la pregunta principal fue cómo se pueden conectar los mensajes a las clases. Esa fue la razón por la que surgieron las interfaces de sistema IF_T100_MESSAGE y IF_T100_DYN_MSG que se pueden vincular a clases para hacer que las clases sean portadoras de mensajes. Sin embargo, esto genera complejidad debido a una doble dirección indirecta.

Los objetos IF_T100_MESSAGE y IF_T100_DYN_MSG, y en particular los objetos de excepción, también pueden convertirse en portadores de cualquier mensaje. Esto permite que las excepciones «antiguas» se conviertan en nuevas. La sintaxis completa solo se usa para obtener el contenido de los campos del sistema que se completaron con MENSAJE en los atributos de las clases. A continuación, trato de explicarlo todo con más detalles. Entonces, si también tiene curiosidad por saber cómo evolucionó la mensajería en ABAP, acompáñeme.

Manejo de excepciones no basado en clases

Antes de que se inventaran los mensajes basados ​​en clases, una forma de manejar los mensajes era usando el módulo de función:

FUNCTION ZMSG_FUNC.
  IF p IS INITIAL.
    MESSAGE e000(ZCL_MSG_DEMO).
  ENDIF.
ENDFUNCTION.

Luego llama a la función en el programa.

REPORT zblog.
PARAMETERS p.

AT SELECTION-SCREEN.
  CALL FUNCTION 'ZMSG_FUNC' EXPORTING p = p.

Como antes, el módulo de funciones generará el mensaje de error hasta que el usuario dé un valor a la variable. El punto es que el módulo de función es reutilizable en diferentes situaciones. Además, por medio de los módulos de funciones, podemos manejar la excepción usando el concepto de ‘mensaje de error’. Por ejemplo

  CALL FUNCTION 'ZMSG_FUNC' 
  EXPORTING p = p
    EXCEPTIONS ERROR_MESSAGE = 404.

Aquí, el mensaje de error convierte el mensaje electrónico enviado por el módulo de función en un formulario de excepción de manera que si P está vacío, se mostrará el número dado ‘404’ en la pantalla. Por lo tanto, es como se hizo anteriormente para usar la instrucción del mensaje para enviar una excepción usando la excepción especial ‘mensaje de error’. Por el contrario, si no se gestiona la excepción, se envía el mensaje.

También se puede definir una excepción en un módulo de funciones y usarla mediante el complemento ‘aumentar’. Por lo tanto, la declaración del mensaje se convertirá en una declaración de aumento. La declaración MENSAJE… LEVANTANDO es principalmente una declaración para generar excepciones no basadas en clases y no para enviar mensajes. Solo envía un mensaje si no se maneja la excepción.

Es la otra forma de crear textos de excepción y evitar la finalización del programa.

FUNCTION ZMSG_FUNC.  
IF p IS INITIAL.
    MESSAGE e000(ZCL_MSG_DEMO) RAISING msg_exc.
  ENDIF.
ENDFUNCTION.

En el programa principal

  CALL FUNCTION 'ZMSG_FUNC'
  EXPORTING p = p
    EXCEPTIONS msg_exc = 404.

Como antes, si la excepción no se maneja correctamente, el programa se cerrará. Si no se asigna ningún código de retorno a la excepción, se ignora la adición RAISING y el mensaje se envía utilizando la instrucción MESSAGE y se procesa de acuerdo con su tipo de mensaje.

Si bien el ‘mensaje de error’ no es compatible con la definición de clase, este último también se puede hacer utilizando el concepto orientado a objetos.

CLASS zcl_msg DEFINITION .
  PUBLIC SECTION.

    CLASS-METHODS raise_excp EXCEPTIONS msg_exc.
ENDCLASS.

CLASS zcl_msg IMPLEMENTATION.

  METHOD raise_excp.
    MESSAGE e000(zcl_msg_demo) RAISING msg_exc.
  ENDMETHOD.

ENDCLASS.

START-OF-SELECTION.

  zcl_msg=>raise_excp( ).

Al ejecutar el programa, el mensaje se mostrará como se esperaba:

Tenga en cuenta que esta adición solo tiene sentido durante el procesamiento de métodos y módulos de funciones en los que se define la excepción no basada en clases.

Ese era el mundo antes de la definición de excepción basada en clases. El objetivo de la definición de clase de la excepción era tener clases y objetos como portadores de mensajes, cuyo propósito es convertir los textos de excepción completos en las clases de excepción. Eso fue técnicamente posible al definir las interfaces del sistema IF_T100_MESSAGE y IF_T100_DYN_MSG que permiten asociar objetos con mensajes y mostrarlos usando la instrucción MESSAGE. Esto está pensado principalmente para textos de excepción de clases de excepción.

En tales casos, una forma de definir un mensaje es usando la sintaxis

MENSAJE { oref [TYPE mtype] }

Para oref, se puede especificar una variable de referencia de objeto cuando se ejecuta la declaración MENSAJE, que apunta a un objeto cuya clase implementa la interfaz del sistema IF_T100_MESSAGE. El tipo de mensaje se especifica explícitamente utilizando TYPE mtype o se determina implícitamente. Esto significa que, si la variable de referencia del objeto oref apunta a un objeto que incluye la interfaz del sistema IF_T100_DYN_MSG, se puede omitir la adición TYPE y se usa implícitamente el tipo de mensaje del atributo de interfaz MSGTY del objeto. oref es una posición de operando funcional. Si oref se especifica, la adición CON y la variante con INTO no están permitidas.

Hasta la versión 7.54, la declaración MENSAJE oref solo podría tener las adiciones adicionales RAISING y DISPLAY LIKE si TYPE se especificara explícitamente. Estas adiciones ahora también son posibles si no se especifica TYPE. Un ejemplo detallado se puede encontrar en Documentación de palabras clave ABAP.

Interfaces del sistema para mensajes

Las interfaces del sistema para mensajes (IF_T100_MESSAGE e IF_T100_DYN_MSG) están diseñadas principalmente para textos de excepción y clases de excepción para mensajes.

La interfaz IF_T100_ MENSAJE contiene un atributo estructurado T100KEY con los componentes MSGID y MSGNO que hacen referencia a la clase y el número del mensaje. Sin embargo, no tiene ningún atributo para el tipo de mensaje. La interfaz IF_T100_DYN_MSG agrega atributos predefinidos para el tipo de mensaje y los marcadores de posición del mensaje a la interfaz IF_T100_MESSAGE.

Las propiedades del mensaje especificado después de MENSAJE se asignan automáticamente a los atributos asociados en las clases de excepción que incluyen IF_T100_DYN_MSG. Esto significa que si se usa IF_T100_DYN_MSG, ya no es necesario crear atributos separados para los marcadores de posición del mensaje. En su lugar, se utilizan los atributos de la interfaz. Además, un tipo de mensaje se puede almacenar y evaluar en el atributo de interfaz msgty. Además, IF_T100_MESSAGE está diseñado para textos de excepción estáticos de clases de excepción, pero IF_T100_DYN_MSG puede asociar cualquier mensaje con clases de excepción.

La interfaz IF_T100_DYN_MSG está diseñada específicamente para generar excepciones basadas en clases con el MENSAJE adicional de la declaración RAISE EXCEPTION o la adición THROW en expresiones condicionales.

Con situaciones de error en el programa ABAP, las excepciones se pueden generar de manera controlada por el programa usando el EXCEPCIÓN DE AUMENTO declaración o la adición TIRAR en expresiones condicionales. La forma de sintaxis general es

AUMENTAR EXCEPCIÓN { {TIPO cx_class [message] [EXPORTING p1 = a1 p2 = a2 …]}

• Si se especifica el TIPO adicional, se genera una excepción de la clase de excepción cx_class y, si es necesario, se crea un objeto de excepción. Cada clase de excepción cx_class visible en este punto se puede especificar después de TYPE.
• El mensaje adicional se puede utilizar para vincular el objeto de excepción a un mensaje.
• La adición EXPORTACIÓN se puede utilizar para asignar parámetros reales a los parámetros de entrada del constructor de instancias de la clase de excepción.

El MENSAJE adicional pasa la especificación de un mensaje al objeto de excepción y se puede escribir en forma larga (ejemplo a continuación) o en la forma corta recién definidaUSANDO MENSAJE (desde la versión 7.52). Esta variante es una forma abreviada de la anterior vavariante de la adición de MENSAJE con sintaxis:

... MESSAGE ID          sy-msgid
            TYPE        sy-msgty
            NUMBER      sy-msgno
            WITH        sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 ...

La adición USING MESSAGE pasa implícitamente la especificación del mensaje que se almacena durante la ejecución de la declaración en los campos del sistema sy-msgid, sy-msgty sy-msgno y sy-msgv1 a sy-msgv4 a la clase de excepción. Esta forma abreviada es especialmente adecuada para convertir excepciones clásicas que se generaron en módulos de función o métodos con la instrucción MESSAGE RAISING, o mensajes que se detectaron con error_message, en excepciones basadas en clases.

La funcionalidad completa del MENSAJE adicional está disponible solo si la interfaz del sistema IF_T100_DYN_MSG se implementa en la clase de excepción utilizada. Esto permite determinar el mensaje a partir del contenido actual de los campos del sistema sy-msg.

ejemplo yo

Levantamiento de la excepción CX_DEMO_DYN_T100 que implementa la interfaz IF_T100_DYN_MSG. La adición MENSAJE se utiliza para pasar las propiedades de un mensaje que determina el texto de excepción. A los atributos MSGV1 a MSGV4 de la interfaz IF_T100_DYN_MSG se les asignan los textos especificados con WITH.

CALL FUNCTION 'DEMO_FUNCTION_MESSAGE'
  EXPORTING
    message_type="A"
    message_place="in Function Module"
    message_event="START-OF-SELECTION"
  EXCEPTIONS
    error_message = 4.
"Long form
TRY.
    RAISE EXCEPTION TYPE cx_demo_dyn_t100
            MESSAGE ID  sy-msgid
            TYPE        sy-msgty
            NUMBER      sy-msgno
            WITH   sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 .
  CATCH cx_demo_dyn_t100 INTO DATA(oref).
    cl_demo_output=>display( oref->get_text( ) &&
                             `, ` && oref->msgty ).
ENDTRY.

podemos reescribir el bloque try del ejemplo anterior en la siguiente forma abreviada:

Ejemplo II

El ejemplo demuestra la forma abreviada de la declaración RAISE EXCEPTION con la adición USING MESSAGE.

"Short form
TRY.
    RAISE EXCEPTION TYPE cx_demo_dyn_t100 USING MESSAGE.
  CATCH cx_demo_dyn_t100 INTO DATA(oref).
    cl_demo_output=>display( oref->get_text( ) &&
                             `, ` && oref->msgty ).ENDTRY.

Aquí, se usa la adición USING MESSAGE, que pasa explícitamente los campos del sistema sy-msgty, sy-msgid, sy-msgno y sy-msgv1 a sy-msgv4 a las adiciones correspondientes de la instrucción RAISE EXCEPTION. El ejemplo tiene la misma funcionalidad que el ejemplo ejecutable introducido en la forma larga.

Si necesita más detalles sobre los temas, consulte los hipervínculos que se le proporcionan en el texto, también eche un vistazo a Documentación de palabras clave ABAP.