FWD » Core Development » Runtime Infrastructure

• TestNestedReturn.cls
  

  USING OpenEdge.Core.Assert FROM PROPATH.
  
  BLOCK-LEVEL ON ERROR UNDO, THROW.
  
  CLASS tests.blocklevel.TestNestedReturn:
      @TEST.
      METHOD PUBLIC VOID TestNestedProcedure():
          RUN tests/blocklevel/p-nested-procedure.p.
          Assert:Equals("asdasdas", RETURN-VALUE).
      END METHOD.
  END CLASS.
  

• p-nested-procedure.p
  

  PROCEDURE nested-procedure:
      RETURN "asdasdas".
      FINALLY:
          tests.blocklevel.DummyClass:call1().
      END FINALLY.
  END PROCEDURE.
  
  RUN nested-procedure.
  RETURN RETURN-VALUE.
  

• DummyClass.cls
  

  CLASS tests.blocklevel.DummyClass:
      METHOD PUBLIC STATIC VOID call1():
          RETURN.
      END METHOD.
  END CLASS.
  

On FWD, on DummyClass:call1 overwrites the return value from nested-procedure and in this case, we end up with "" as return value from RUN tests/blocklevel/p-nested-procedure.p. in TestNestedProcedure test. The Assert fails because "asdasdas" is not equal with "".

• It is normal on 4GL to change the return of a procedure from a FINNALY block when there are other procedure calls that use RETURN statement.
• 4GL does not change procedure RETURN-VALUE on a RETURN statement in a method that return void, but FWD changes it. On non-void methods, FWD does not change the RETURN-VALUE.

The cause of this problem:

4GL code4GL code

CLASS tests.blocklevel.DummyClass:
    METHOD PUBLIC STATIC VOID call1():
        RETURN TRUE.
    END METHOD.
END CLASS.

public class DummyClass
extends BaseObject
{
   @LegacySignature(type = Type.CONSTRUCTOR, name = "DummyClass")
   public void __tests_blocklevel_dummyClass_constructor__()
   {
      internalProcedure(DummyClass.class, this, "DummyClass", new Block((Body) () -> 
      {
         __lang_BaseObject_constructor__();
      }));
   }

   @LegacySignature(type = Type.METHOD, name = "call1")
   public static void call1()
   {
      ObjectOps.load(DummyClass.class);

      // Instead of function block, this gets into internalProcedure, that tricks BlockManager.returnWorker to think that this is a procedure. !!!
      internalProcedure(DummyClass.class, "call2", new Block((Body) () -> 
      {
         storeReturnValue();
      }));
   }
}

I was told (many years ago) by someone at Progress, that they implemented OO methods in this way:

• If the method returns VOID, then it is treated as an internal procedure.
• If the method has a return value, then it is treated as a function.

This is why we map things as we do (e.g. to BlockManager.internalProcedure() for a void method). In this case, we should just ignore the RETURN TRUE. statement. But we don't fully ignore it.

Please check if a non-OO true internal procedure case also has this bug in FWD.

On OpenEdge, when using a true non-OO true internal procedure, the RETURN statement will write the RETURN-VALUE attribute. This also happens in FWD, this is not a problem here.
When using OE OO void method, the only valid statement is RETURN., which does not write "" into RETURN-VALUE attribute.

Teodor, is this about the FINALLY block? You can test this without OO.

Constantin Asofiei wrote:

Teodor, is this about the FINALLY block? You can test this without OO.

• p-nested-procedure.p
  

  PROCEDURE nested-procedure:
      RETURN "asdasdas".
      FINALLY:
          RUN p-return.
      END FINALLY.
  END PROCEDURE.
  
  RUN nested-procedure.
  RETURN RETURN-VALUE.
  /* The return value is "" */
  

• TestNestedReturn.cls
  

  USING OpenEdge.Core.Assert FROM PROPATH.
  
  BLOCK-LEVEL ON ERROR UNDO, THROW.
  
  CLASS TestNestedReturn:
      @TEST.
      METHOD PUBLIC VOID TestNestedProcedure():
          RUN p-nested-procedure.p.
          Assert:Equals("", RETURN-VALUE).
      END METHOD.
  END CLASS.
  

• p-return.p
  

  RETURN.
  

Committed revision 15991 on task branch 10174a:
- fixed regression when using BlockManager.returnNormal.

Danut and Lorian told to me that now the tests passes. I have done some smoke tests and some harness tests on two customer apps and it seems OK now.

rtype ReturnType.STORE should match also on rtype ReturnType.NORMAL. Was rtype != ReturnType.ERROR matching on CONSUME also? Because as it is now it doesn't look right to me.

Constantin Asofiei wrote:

rtype ReturnType.STORE should match also on rtype ReturnType.NORMAL. Was rtype != ReturnType.ERROR matching on CONSUME also? Because as it is now it doesn't look right to me.

I am investigating this right now.
There were some regressions and I have just put rtype == ReturnType.STORE because the test that I found uses storeReturnValue. I am looking for the cases where returnNormal and returnConsume is used and test them on 4GL.

There is also this for CONSUME:

               if (rtype == ReturnType.CONSUME && isPersistentTriggerTopLevel(wa))
               {
                  LogicalTerminal.consumeEvent();
               }

Committed revision 15993 on task branch 10174a:
- Addressed code review #10174-18: moved the if condition, so the LogicalTerminal.consumeEvent() can get executed on ReturnType.CONSUME.