FWD » Core Development » Base Language

This program:

do on stop undo, leave:
   run missing3.p no-error.
end.
message "done".

Must log the missing3.p was not found error message in the client log. Currently, FWD does not do this in ErrorManager.displayError, if silent mode is enabled.

Also, with 5753d, ControlFlowOps.invokeFailure was changed from this:

   private static void invokeFailure(String target)
   throws StopConditionException
   {
      String spec = "\"%s\" was not found";
      String err  = String.format(spec, target);
      err = ErrorManager.buildErrorText(293, err, true);

      ErrorManager.displayError(err, false, null);
      throw new StopConditionException(err, new NumberedException(err, 293));
   }

   private static void invokeFailure(String target)
   throws StopConditionException
   {
      String spec = "\"%s\" was not found";
      String err  = String.format(spec, target);

      ErrorManager.displayError(293, err, true);
      throw new StopConditionException(err, new NumberedException(err, 293));
   }

   public static void displayError(int num, String msg, boolean prefix)
   {
      boolean manageLegacyError = da.mustThrowLegacyError();

      msg = buildErrorText(num, msg, prefix);
      if (manageLegacyError)
      {
         da.recordForLegacyThrow(msg, num);
         throw new DeferredLegacyErrorException();
      }

      displayError(msg);
      addRaisedCondition(new int[] {num});
   }

This may not be correct, as the STOP condition will be prevented if mustThrowLegacyError() is true.

I mentioned 'log' in the title and previous entry, but this is also about displaying the error message to the user. OE always displays the 'was not found' message, regardless of NO-ERROR when running an external program and that program is not found. This program:

run missing in this-procedure no-error.
do on error undo, leave:
   run missing2 in this-procedure.  // this is logged to clientlog
end.

do on stop undo, leave:
 run missing3.p no-error.
end.
message "done".

[23/04/12@21:11:20.819+0300] P-002324 T-003368 1 AS -- (Procedure: 'a.p' Line:3) Procedure a.p has no entry point for missing2. (6456)
[23/04/12@21:11:20.822+0300] P-002324 T-003368 1 AS -- (Procedure: 'a.p' Line:7) ** "missing3.p" was not found. (293)
[23/04/12@21:11:20.822+0300] P-002324 T-003368 1 AS -- (Procedure: 'a.p' Line:9) done

and the same messages are displayed in the GUI/ChUI client.

This bug already exists in trunk, it came up in a discussion when debugging a customer's application.

Constantin Asofiei wrote:

Also, with 5753d, ControlFlowOps.invokeFailure was changed from this:
[...]
to this:
[...]
where ErrorManager.displayError(293, err, true); is:
[...]

This has been restored to the original before 5753d was merged, so it's not related. Discussed in #5753#note-242, #5753#note-243, #5753#note-244.

Galya, this is not a bug related to your changes. This is an existing bug which we need to fix; please see this test:

def var h as handle.

message "case 1".
do on stop undo, leave:
   run missing.p  no-error.
   message "must not show 1".
end.
message "1" error-status:error error-status:get-message(1). // 1 no ** "missing.p" was not found. (293)

message "case 2".
do on stop undo, leave:
   run missing.p .
   message "must not show 2".
end.
message "2" error-status:error error-status:get-message(1). // 1 no ** "missing.p" was not found. (293)

output to a.txt.
/*
a.txt content:

case 3
** "missing.p" was not found. (293)
3 no ** "missing.p" was not found. (293)
case 4
** "missing.p" was not found. (293)
4 no ** "missing.p" was not found. (293)

*/
message "case 3".
do on stop undo, leave:
   run missing.p  no-error.
   message "must not show 3".
end.
message "3" error-status:error error-status:get-message(1).

message "case 4".
do on stop undo, leave:
   run missing.p .
   message "must not show 4".
end.
message "4" error-status:error error-status:get-message(1).
output close.

Run it from both an standalone client and via appserver. When ran on appserver, these must be logged:

[23/05/01@15:18:00.156+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:3) case 1
[23/05/01@15:18:00.161+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:5) ** "missing.p" was not found. (293)
[23/05/01@15:18:00.161+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:8) 1 no ** "missing.p" was not found. (293)
[23/05/01@15:18:00.161+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:10) case 2
[23/05/01@15:18:00.161+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:12) ** "missing.p" was not found. (293)
[23/05/01@15:18:00.161+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:15) 2 no ** "missing.p" was not found. (293)
[23/05/01@15:18:00.162+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:29) case 3
[23/05/01@15:18:00.162+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:31) ** "missing.p" was not found. (293)
[23/05/01@15:18:00.162+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:34) 3 no ** "missing.p" was not found. (293)
[23/05/01@15:18:00.162+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:36) case 4
[23/05/01@15:18:00.162+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:38) ** "missing.p" was not found. (293)
[23/05/01@15:18:00.162+0300] P-004228 T-003908 1 AS -- (Procedure: 'testmissing.p' Line:41) 4 no ** "missing.p" was not found. (293)

We are missing these messages, either in the appserver log, the file or on screen.

Constantin, I'm testing it now. I just wanted to make clear it's not related to the above mentioned change.

I'll focus on 1. for this task. Starting to debug.

I think the issue is in the converted code that considers it a silent invokation:

public class TestMissing
{
   private static final InvokeConfig RUN_CALL_SITE_1 = new InvokeConfig().setTarget("missing.p");

   private static final InvokeConfig RUN_CALL_SITE_2 = new InvokeConfig().setTarget("missing.p");

   private static final InvokeConfig RUN_CALL_SITE_3 = new InvokeConfig().setTarget("missing.p");

   private static final InvokeConfig RUN_CALL_SITE_4 = new InvokeConfig().setTarget("missing.p");

   @LegacySignature(type = Type.MAIN)
   public void execute()
   {
      externalProcedure(Fail.this, new Block((Body) () -> 
      {

         [...]

         doBlock(TransactionType.SUB, "blockLabel0", onPhrase0, new Block((Body) () -> 
         {
            silent(() -> RUN_CALL_SITE_1.clone().run());
            message("must not show 1");
         }));

         [...]

         doBlock(TransactionType.SUB, "blockLabel1", onPhrase1, new Block((Body) () -> 
         {
            RUN_CALL_SITE_2.clone().run();
            message("must not show 2");
         }));
      }));
   }
}

Do you think it should be fixed conversion time?

• keep the STOP condition being raised
• properly add the error message to ERROR-STATUS and also display it.

Constantin Asofiei wrote:

Galya, please focus on ControlFlowOps.invokeFailure - the problem is there, we need to adjust that code to:

• keep the STOP condition being raised

I believe the stop condition is always raised. must not show message is never shown in my tests.

Galya Bogdanova wrote:

Constantin Asofiei wrote:

Galya, please focus on ControlFlowOps.invokeFailure - the problem is there, we need to adjust that code to:

• keep the STOP condition being raised

I believe the stop condition is always raised. must not show message is never shown in my tests.

Correct.

Constantin Asofiei wrote:

• properly add the error message to ERROR-STATUS and also display it.

Just to make it clear: This will not fix the missing alerts, because the error is considered silent in the converted code. It will just fix issues 2. and 3. (check #7272#note-10) and from the description of the task I thought we need to fix 1.

But let me see what I can do about 2. and 3.

Constantin Asofiei wrote:

Galya Bogdanova wrote:

Constantin Asofiei wrote:

Galya, please focus on ControlFlowOps.invokeFailure - the problem is there, we need to adjust that code to:

• keep the STOP condition being raised

I believe the stop condition is always raised. must not show message is never shown in my tests.

Correct.

But that is the OE behavior. What do I fix?

Galya Bogdanova wrote:

I believe the stop condition is always raised. must not show message is never shown in my tests.

Correct.

But that is the OE behavior. What do I fix?

Nothing to fix, just a note that this is important.

Regarding #7272-16 - please solve also the missing alert - if with NO-ERROR OpenEdge still displays the error dialog/message in a ChUI/GUI client, we need to behave the same. This behavior is out of the normal silent error mode in OpenEdge, as the ERROR-STATUS is recording this error message regardless if NO-ERROR is present or not.

Constantin Asofiei wrote:

Regarding #7272-16 - please solve also the missing alert - if with NO-ERROR OpenEdge still displays the error dialog/message in a ChUI/GUI client, we need to behave the same. This behavior is out of the normal silent error mode in OpenEdge, as the ERROR-STATUS is recording this error message regardless if NO-ERROR is present or not.

This should not be considered silent in FWD - it should display an alert and fill in ERROR-STATUS, so the problem is the ErrorManager.silent() wrapper in the converted code. There is nothing silent left in this error.

Galya Bogdanova wrote:

This should not be considered silent in FWD - it should display an alert and fill in ERROR-STATUS, so the problem is the ErrorManager.silent() wrapper in the converted code. There is nothing silent left in this error.

The NO-ERROR affects argument processing, too; not just ControlFlowOps.invokeFailure. So we can't remove it from converted code.

I think it may be possible to disable silent error processing in ControlFlowOps.invokeFailure and re-enable it (if it was previously enabled). This may help - see ErrorManager.setSilent and isSilent.

Constantin Asofiei wrote:

I think it may be possible to disable silent error processing in ControlFlowOps.invokeFailure and re-enable it (if it was previously enabled). This may help - see ErrorManager.setSilent and isSilent.

This is the ErrorManager code responsible for handling that part of the converted procedure:

private static boolean silentWorker(Runnable code, ServerDataAccess srv, WorkArea wa)
      // enable silent error processing
      boolean wasSilent = wa.silent;
      if (!wasSilent)
      {
         srv.setSilent(wa, true);
      }

      try
      {
         code.run();
      }
[...]

At this point I don't know if the code is a RUN external.p.

The Runnable code is () -> new InvokeConfig().setTarget("external.p").run().

The only field set in InvokeConfig is target. Is the presence of it enough to identify the executed code as RUN external.p?

On line 7159 in ControlFlowOps.invokeImpl the error is to be displayed with invokeFailure(name):

         if (caller == null)
         {
            String pname = wa.pm.getRelativeName(h.get());
            if (function)
            {
               [...]
            }
            else if (explicit)
            {
               [...]
            }

            invokeFailure(name);
            return result;
         }

So there is not much else into the matter.

Basically the only clue we have runtime about what is going on is the InvokeConfig field target value is set and no other arguments are present, but I don't know if this is applicable only to RUN external.p.

Galya, invokeFailure is ever only called for a failure of a RUN externalprogram.p statement; it never gets called when invoking functions or internal procedures. There are some OO cases (like class initialization), but these can be ignored for now.

So when invokeFailure is reached you know that this is a case of an external program.

Galya Bogdanova wrote:

Constantin Asofiei wrote:

So when invokeFailure is reached you know that this is a case of an external program.

Are you sure? Here it's called on NoSuchMethodException.

This is what " There are some OO cases (like class initialization), but these can be ignored for now." comment is for. I'll work on some OO tests to check once the RUN case is fixed.

Do we expect to see alert boxes?

This code always receives noMessageBox = false and transforms it in true with all client drivers.

 public static void displayError(String errmsg, boolean noMessageBox, boolean logCallStack,
                                   boolean isFromLogManager)
   {
      noMessageBox |= !ErrorManager.isSystemAlertBoxes();

Run the test with session:system-alert-boxes = false. or session:system-alert-boxes = true., in ChUI and GUI, and see how it behaves.

I think we need to restore the silent mode, something like this:

boolean isSilent = ErrorManager.isSilentError();
if (isSilent)
{
   ErrorManager.setSilent(false);
}
try
{
   ErrorManager.addError(errCode, errMsg, false, true);
   ErrorManager.displayError(err);
   throw new StopConditionException(err, new NumberedException(err, errCode));
}
finally
{
   if (isSilent)
   {
      ErrorManager.setSilent(true);
   }
}

Regarding the unexpected lines, yes, please look into it. Also, is system-alert-boxes behavior working OK?

Constantin Asofiei wrote:

Also, is system-alert-boxes behavior working OK?

It works only in gui, where errors are by default displayed as message boxes and with session:system-alert-boxes = false gui disables error message box. But for both chui swing and terminal session:system-alert-boxes = true doesn't take effect. I'm not sure if that's how it's supposed to work.

session:system-alert-boxes = true. works for both ChUI and GUI OpenEdge clients (displays dialog-box).

Do we create a separate task? This one will get some time if I need to address all of the issues. Not sure how urgent is the test fix.

Galya Bogdanova wrote:

Do we create a separate task? This one will get some time if I need to address all of the issues. Not sure how urgent is the test fix.

Leave the system-alert-boxes on the side for now. Focus on the original test.

Can I run .p file in Progress in GUI? I wonder if the system bar messages are even displayed after the redirect to the file.

Galya Bogdanova wrote:

Can I run .p file in Progress in GUI? I wonder if the system bar messages are even displayed after the redirect to the file.

prowin -p testme.p is how you can launch a program for GUI in OpenEdge.

Galya, please add your changes to the 7272a branch.

Constantin Asofiei wrote:

Galya, please add your changes to the 7272a branch.

Up in 7272a r14554-14556.

Galya, I don't understand the Window.java change - in ChUI, this code emits the error message, in OpenEdge, in the terminal's message area:

def var h as handle.
output to a.txt.
h:name = "abc".
output close.

• the message area, where MESSAGE statement or error messages are written
• the status area, where STATUS statement can be used.

In OE if you run the procedure as batch: pro -b -p proc.p, this is what I'm referring to chui (probably not the right term). When running as batch there is no message area and nothing is displayed anywhere after the output to file statement.

Our "message" ends up straight on the terminal with batch and chui-terminal, while it's not expected there.

Then this condition is not right boolean switchedOnChui = tc.isChui() && switched; .

Batch is a kind of ChUI client, while terminal is another kind of ChUI client. As I understand, this condition needs to be only for batch mode - using tc.isChUI() is too generic. Use OutputManager.inBatchMode() if you want to know if a client is in batch mode.

What is chui terminal in OE? In FWD it doesn't have that message area on the bottom, so it looks like batch.

Galya Bogdanova wrote:

What is chui terminal in OE? In FWD it doesn't have that message area on the bottom, so it looks like batch.

• ChUI terminal in OE is started via pro command. This is the character interface, in FWD can be launched via the native ChUI client, Swing ChUI client or Web ChUI client. All should behave the same, but we care only about the native ChUI client mostly, at this time.
• batch in OE is started via bpro command. This is a 'kind of' character interface (as all calculation for FRAMEs is done in characters), and in FWD is launched via batch processes.
• GUI clients in OE are started via prowin. FWD has Swing or Web GUI clients.

OK, I get confused by all the garbage output from System.err (hopefully some day it will go away). It's indeed a change to be done only for batch.

Fixed in 7272a r14557.

• in ChUI (terminal) - if the message on the screen and in the file are the same
• in Batch - if the message on the screen and in the file are the same
• in GUI - if the message on the screen and in the file are the same
• in appserver - if the logged messages are the same.

For appserver do we somehow narrow down the condition in Window further by excluding appserver.

Thanks, I think we are OK with what we wanted to solve in this task. Regarding appserver - I see messages being logged in all 4 cases, so is enough for now.

Greg: we are OK to merge to trunk.

Go ahead with the merge.

Task branch 7272a was merged to the trunk as rev 14555 and archived.