Error in logical expression COND 1 = 1

[former_member195315]

Hello, guys.

The following piece of code can be activated:

IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.

ENDIF.

But the one below cannot. It throws the message Error in logical expression.

IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ).

ENDIF.

Does anyone know why and what can be done so code can be activated?

The code is just an example.

The _posting_allowed( ) is a method which return TRUE or FALSE.

[former_member195315]

Hello, guys.

The following piece of code can be activated:

IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.

ENDIF.

But the one below cannot. It throws the message Error in logical expression.

IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ).

ENDIF.

Does anyone know why and what can be done so code can be activated?

The code is just an example.

The _posting_allowed( ) is a method which return TRUE or FALSE.

[ChrisSolomon]

Patrick, in newer versions you can actually say something like "IF A.".....if A translates to a boolean....you can also use methods that return a boolean such as "IF me->check_is_valid( somevalue )." .

[joltdx]

Predicative method calls are available since 7.40 SP08. (I did not know by heart - I had to look that version number up in this blog post).

I guess you're on a version earlier than that...

[former_member195315]

jorgen_lindqvist41, thanks for replying.Current version is 7.54.Do you think it could be a framework problem?

[joltdx]

Hah, ok, new answer... This was interesting... 🙂

[freek_cavens2]

The problem occurs with both "IF" and "CHECK" (and Value, as you say, but there I have always been able to bypass it somehow without being annoyed enough to make a fuzz out of it...).

The following is not possible :

• IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ).
• CHECK _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ).

But this is :

• IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.
• CHECK _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.
• IF _posting_allowed( i_par = 1 ).
• CHECK _posting_allowed( i_par = 1 ).

So it is as you say, there seems to be some kind of mix up in the parser. So either Horst will come up with an answer here or Alejandro will log it for us with SAP and we'll go the offiical way.

[Patrick_vN]

I thought so too, but I didn't find anything about it in abapdocu. So, from which version it is available?

Just tried on an S4H1909 and it doesn't activate ;).

[joltdx]

Yeah, this has got to be a bug then. Any input, horst.keller?

I did some more testing and theorizing here... Documentation links:

• IF
• COND
• log_exp
• rel_exp - Predicative method calls
• rel_exp - Comparison expressions

The relevant syntax of the IF statement in this case is

IF log_exp_if.

And the COND is

COND type( WHEN log_exp_cond THEN result_cond ).

I can't see that COND should not be allowed and working in a log_exp, and it is working when we use '= abap_true' as part of the log_exp_if like this:

IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.

But when we remove the '= abap_true' part of the log_exp_if, we get 'Error in logical expression.

My guess is that the parsing or linting of the logical expression log_exp_if is failing when it has no comparison expression in it and there is another logical expression log_exp_cond inside it. It somehow mixes them both together...

Same result also when I wrap the COND in a VALUE operator...

This works in steampunk environment, so it's either fixed in later releases or it's only working there because reasons...