Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Uncatchable runtime error on returning method call

Former Member
0 Kudos


We are observing a strange error handling behavior on a "EHP6 FOR SAP ERP 6.0" system with SAP_BASIS release 740, SP-Level 0006.

We are able to catch the runtime error/exception of an invalid type conversion if we do it within a method.

But we are not able to catch the same runtime error/exception when the conversion happens on a method's return value.

It is a BCD_FIELD_OVERFLOW which is supposed to be catchable.

See the attached minimal program to reproduce the situation. You can also comment in the error handling lines in method same_error_leads_to_dump (either the ones with one asterisk or the ones with two asterisks) to confirm that the error is not handled.

Please keep in mind that our concern is not type conversion but error handling.

The corresponding real world scenario is a large parser dealing with many different fields.

Therefore we need to handle type conversion errors gracefully while we keep eliminating the causes one by one.

Could anyone give me a hint how to handle this error?

1 ACCEPTED SOLUTION

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

The answer is that it is a kind of missing functionality that it is on the agenda for an upcoming release.

As of Release 7.40, you can use the conversion operator CONV in order to achieve the expected behavior:



TYPES dec8 TYPE p LENGTH 8.
TYPES dec1 TYPE p LENGTH 1.

CLASS demo DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS main RETURNING VALUE(p8) TYPE dec8.
ENDCLASS.

CLASS demo IMPLEMENTATION.
  METHOD main.
    p8 = 12345.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

  DATA p1 TYPE dec1.

  TRY.
     "p1 = demo=>main( ).
      p1 = CONV dec8( demo=>main( ) ).
    CATCH cx_sy_conversion_overflow.
  ENDTRY.

Before 7.40, you can use the trick to add a zero in another type in order to get the exception:


START-OF-SELECTION.
  DATA p1 TYPE dec1.
  DATA df TYPE DECFLOAT34.

  TRY.
     p1 = demo=>main( ) + df.
    CATCH cx_sy_conversion_overflow.    
  ENDTRY.

The calculation type is decfloat34 and the exception occurs when assigning the result of the calculation.

All in all clearly a missing feature. A functional mehtod call shouldn't behave differently than other expressions.

5 REPLIES 5

matt
Active Contributor
0 Kudos

There's been some discussion in similar areas before - e.g. and I recall another one where DO 1000000000000 TIMES triggered an uncatchable BCD_FIELD_OVERFLOW.

It's something to do with the way parameters are handled. It looks like the only workaround is to use helper variables, as you have done in your example.

Perhaps might know?

SuhaSaha
Advisor
Advisor
0 Kudos

Something to tickle your grey cells

I was never realised that the syntax checker doesn't check the type compatibility for RETURNING params. Anyway i read the SAP documentation for RETURNING params and apparently the type checking is different from them -


In the typing check,special rules apply, depending on whether an explicit actual parameter is bound with RECEIVING or the functional method is used in an operand position.

Refer - ABAP Keyword Documentation.

I don't quite understand this part though


Checking of this typing is not necessary (or is always successful). An error always occurs, however, if the typing of the return value does not match the operand type.

BR,

Suhas

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

The answer is that it is a kind of missing functionality that it is on the agenda for an upcoming release.

As of Release 7.40, you can use the conversion operator CONV in order to achieve the expected behavior:



TYPES dec8 TYPE p LENGTH 8.
TYPES dec1 TYPE p LENGTH 1.

CLASS demo DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS main RETURNING VALUE(p8) TYPE dec8.
ENDCLASS.

CLASS demo IMPLEMENTATION.
  METHOD main.
    p8 = 12345.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

  DATA p1 TYPE dec1.

  TRY.
     "p1 = demo=>main( ).
      p1 = CONV dec8( demo=>main( ) ).
    CATCH cx_sy_conversion_overflow.
  ENDTRY.

Before 7.40, you can use the trick to add a zero in another type in order to get the exception:


START-OF-SELECTION.
  DATA p1 TYPE dec1.
  DATA df TYPE DECFLOAT34.

  TRY.
     p1 = demo=>main( ) + df.
    CATCH cx_sy_conversion_overflow.    
  ENDTRY.

The calculation type is decfloat34 and the exception occurs when assigning the result of the calculation.

All in all clearly a missing feature. A functional mehtod call shouldn't behave differently than other expressions.

0 Kudos

Thank you, Horst.

Do you know if there is a way to identify all affected lines by statical code analysis?

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

Sorry, but I'm not too much an expert in that.