Skip to Content
Technical Articles

Not able to catch dynamic exceptions inheriting from CX_DYNAMIC_CHECK

My intention:

I wanted to fix all dumps like  CONVT_NO_NUMBER / CX_SY_CONVERSION_NO_NUMBER once and for all in Idoc processing, as dumping does not change the idoc status and therefore idocs do not show up in monitoring.

During the developer test I found out that the exception ( inheriting from CX_DYNAMIC_CHECK ) was not propagated to back the caller and therefore the exceptions could not be caught by my modification.

So I did some research in SCN or internet, but I did not find anything about that topic..

 

Therefore I wrote some examples to test the behavior:

 

Snippet 1: normal assignment, catch is working

DATA gv_char1 TYPE char128 VALUE 'TEST1'.
DATA gv_2 TYPE i.

  TRY.
      gv_2 = gv_char1. "can be catched
    CATCH cx_sy_conversion_no_number .
      WRITE: / 'ERROR'.
  ENDTRY.

 

 

Snippet 2: internal conversion at control structures: catch is not working, as exception is not thrown (dump w/o exception)

DATA gv_char1 TYPE char128 VALUE 'TEST1'.
DATA gv_2 TYPE i.

  TRY.
      IF gv_char1 = 0. WRITE: 'is 0'. ENDIF."dumps
    CATCH cx_sy_conversion_no_number .
      WRITE: / 'ERROR1'.
  ENDTRY.

 

Snippet 3:  “catch by caller”, dumps

CLASS lcl_app DEFINITION.
  PUBLIC SECTION.
    DATA gv_char1 TYPE char128 VALUE 'TEST0'.
    DATA gv_2 TYPE i.
    METHODS test.

ENDCLASS.

CLASS lcl_app IMPLEMENTATION.
  METHOD test.
    gv_2 = gv_char1.
  ENDMETHOD.
ENDCLASS.

  TRY.
      NEW lcl_app( )->test( )."dumps
    CATCH cx_sy_conversion_no_number .
      WRITE: / 'ERROR'.
  ENDTRY.

 

Snippet 4: catch by caller, method contains exception in signature  ( although exception inherits from CX_DYNAMIC_CHECK ) works,

CLASS lcl_app DEFINITION.
  PUBLIC SECTION.
    DATA gv_char1 TYPE char128 VALUE 'TEST0'.
    DATA gv_2 TYPE i.
    METHODS test2 RAISING cx_sy_conversion_no_number.

ENDCLASS.

CLASS lcl_app IMPLEMENTATION.
   METHOD test2.
    gv_2 = gv_char1.
  ENDMETHOD.
ENDCLASS.

  TRY.
      NEW lcl_app( )->test2( )."catch
    CATCH cx_sy_conversion_no_number .
      WRITE: / 'ERROR'.
  ENDTRY.

 

Snippet 5: Call function, dumps.

  TRY.
      CALL FUNCTION 'Z_CONV_NO_NUMBER'.
    CATCH cx_sy_conversion_no_number .
      WRITE: / 'ERROR1'.
  ENDTRY.        .

with

FUNCTION Z_CONV_NO_NUMBER.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"----------------------------------------------------------------------

DATA lv_char1 TYPE char128 VALUE 'TEST1'.
DATA lv_2 TYPE i.

 lv_2 = lv_char1.

ENDFUNCTION.

 

Snippet 6: external perform dumps

  TRY.
      PERFORM conv_no_number IN PROGRAM z_conv_no_number.
    CATCH cx_sy_conversion_no_number .
      WRITE: / 'ERROR1'.
  ENDTRY. 

with

REPORT z_conv_no_number.

FORM conv_no_number.
  DATA lv_char1 TYPE char128 VALUE 'TEST1'.
  DATA lv_2 TYPE i.

  lv_2 = lv_char1.
ENDFORM.

 

Conclusion

So my assumption is that propagation works only inside one program group.But I did not find anything about that in the documentation.

Do you know this?

 

Our netweaver is 7.50 SP16, Kernel 753 PL 500.

 

 

 

 

2 Comments
You must be Logged on to comment or reply to a post.
  • Text for “snippet 5” is missing (function module). I’d expect that it short dumps.

    If you don’t catch the exception and if you don’t declare the exception in the procedure definition with the RAISING word, then the exception CX_SY_NO_HANDLER is triggered (with PREVIOUS = the uncaught exception), and if you don’t catch the latter in the calling procedure with CATCH then there’s a short dump UNCAUGHT_EXCEPTION.

    Whatever you use an internal or an external subroutine, I think that it’s the same behavior. What is important is the use of FORM … RAISING …

    So, you won’t be able to catch all conversion exceptions at the upper level. Catching at the upper level is only possible with class-based exceptions inheriting from CX_NO_CHECK.