Inconsistent exception handling in WD12

Hi,

Something seems to have changed in the exception handling of WD12 - and not for the better.

Some time ago, in WD11, I wrote a function to find out (at runtime) if some window
contains a certain local procedure. Like many of you, I discovered that Windev does not provide this information, so I wrote it myself. The approach is simple: just launch the procedure with a ridiculous number of parameters (40), and then query ExceptionInfo(errCode). If it returns 1027 then the procedure does not exist, and if it returns some other code then it must refer to mismatched parameters.

This worked well upto (and NOT including) WD12. Certain situations which triggered an exception in WD11 do not trigger an exception in WD12 anymore. And to make things worse: I have discovered an inconsistency, meaning that a certain situation does not trigger an exception the first time, but later on it does!

To get to the heart of the matter, I created a little test project which clearly shows the difference in behaviour between WD11 and WD12. The project contains only two windows, WIN_Window1 and WIN_Window2.

WIN_Window1 (with only one button):

Global Declarations:
Counter is int

Click Button1:
sProcedure is string
sProcedures is string = "aa,bb,cc,dd"
sErrMesg is string

IF Counter = 4 THEN Counter = 0
Counter++
sProcedure = ExtractString(sProcedures,Counter,",")

IF WinStatus("WIN_Window2") = NotFound THEN
OpenSister("WIN_Window2")
END
EndTrace()

WHEN EXCEPTION IN
// Try to run procedures aa, bb, cc and dd in WIN_Window2
// aa : exists, but does not take any parameters
// bb : does not exist
// cc : exists, but takes only one parameter, not three
// dd : does not exist
ExecuteProcess("WIN_Window2." + sProcedure, trtProcedure, "Param1", "Param2", "Param3")
DO
sErrMesg = ExceptionInfo(errFullDetails)
ELSE
sErrMesg = "No Exception"
END

Trace(sProcedure)
Trace(sErrMesg)

WIN_Window2 (without any controls):

Local Procedure aa:
PROCEDURE aa()
Trace("Running procedure aa")

Local Procedure cc:
PROCEDURE cc(psParam1 is string)
Trace("Running procedure cc with parameter", psParam1)

Every time you click on the button in WIN_Window1 one of four procedures is tested in WIN_Window2 (see comment in code).

This is what I get in WD11:

1st click: exception 1003 "Ressource non chargée" (as expected)
2nd click: exception 1027 "bb procedure unknown" (as expected)
3rd click: exception 1003 "Ressource non chargée" (as expected)
4th click: exception 1027 "dd procedure unknown" (as expected)

5th click: exception 1003 "Ressource non chargée" (as expected)
6th click: exception 1027 "bb procedure unknown" (as expected)
7th click: exception 1003 "Ressource non chargée" (as expected)
8th click: exception 1027 "dd procedure unknown" (as expected)

And now for WD12:

1st click: No exception ??? (NOT as expected)
2nd click: exception 1027 "bb procedure unknown" (as expected)
3rd click: exception 1027 "bb procedure unknown" (1027? procedure bb?)
4th click: exception 1027 "dd procedure unknown" (as expected)

5th click: exception 1027 "dd procedure unknown" (it gets weirder)
6th click: exception 1027 "bb procedure unknown" (as expected)
7th click: exception 1027 "bb procedure unknown" (totally lost here)
8th click: exception 1027 "dd procedure unknown" (as expected)

This is what it looks like: Exceptions as a result of mismatched parameters do not update the ExceptionInfo information anymore. Instead you get the information belonging to the previous exception. As for the first click, which fails to trigger an exception at all: this worries me a lot. Every new release will have some bugs in it, but inconsistent behaviour usually means serious trouble.

Any thoughts on this? Anybody had similar problems with exception handling?

/sohan

Hi...

I'm not sure the problem is coming from the exceptions management... Because if I remember correctly, WinDev 12 now accepts a VARIABLE number of parameters in procedure calls...

So the first call should not create an exception,and afterward, the strange behavior may come from the fact that of course you are not processing the extra parameters...

Best regards

Fabrice Harari
WinDev, WebDev, WinDev Mobile Video Courses

Hi Sohan,

My first thought was the same as Fabrice, although if I understand the helpfile correctly for a variable numer of parameters you need to pass an asterisk.
My second thought is: why do you want to test the existence of a procedure ahead of it's use? If you call it and you get an error, process the error to do just nothing. (Saves some code lines too)
If you want to render some buttons invisible if a procedure does not exist, you could use an extra boolean parameter in the procedure. If set, the procedure returns directly, without any action. Of course this needs some extra adaptations that you probably want to avoid. However, it will make your code less vulnarable for future changes in Windev

Best regards,
Piet

Hello Fabrice,

Thanks for your reply.

I thought of that too, this new feature of passing a variable number of parameters to a procedure. But if memory serves me right, it must explicitly be declared as PROCEDURE MyProc(*), indicating that the procedure ACCEPTS a variable number of parameters.

The concerns I have are:

- Click #1 and click #5 both result in executing exactly the same function, with exactly the same parameters, under exactly the same conditions (or am I missing something?). So I would expect that Windev behaves exactly the same. It does not.

- Click #1 not only fails to raise an exception, it also does NOT run procedure `aa`. In my book only two scenarios are possible: Either an exception occurs, and information about the nature of the exception in available in ExceptionInfo(), OR everything works as intended and procedure `aa` is run. Click #1 does neither. I does not result in an exception, so I would expect to see "Running procedure aa" in my trace. It is not showing.

- Clicks #3, #5 and #7 trigger an exception, but the information given by ExceptionInfo() is obviously false. They produce error code 1027, but procedures `aa` and `cc` DO exist in WIN_Window2. Also, the textual error message mentions procedures `bb` and `dd`, which are NOT being called by the ExecuteProcess function when the exception occurs. I can only conclude that Windev HAS triggered an exception, but HAS NOT updated the ExceptionInfo information.

Like you, I suspect that the underlying root of this problem is caused by this new feature of passing a variable number of parameters to a procedure. But I sure hope that this is not `intended behaviour`.

/sohan

Hi Piet,

Thanks for your input.

Quote
Piet van Zanten
why do you want to test the existence of a procedure ahead of it's use? If you call it and you get an error, process the error to do just nothing. (Saves some code lines too)

This is exactly what I did before, and it created big trouble:

WHEN EXCEPTION IN
ExecuteProcess("WIN_Window2.SomeProc", trtprocedure, ...)
DO
//nop
END

When the developer of WIN_Window2 did create procedure `SomeProc`, then any and all exceptions occuring during its execution (which are not being handled explicitly) are being eaten by the calling WHEN EXCEPTION construct. I spent some time debugging such code, only to find that my method of calling the procedure also hides the exceptions occurring inside that procedure. That is why I first want to find out whether the procedure exists, and if does exist, run the procedure WITHOUT the exception trapping construct.

I searched the (old) forum for this topic, and I found several posts of people wanting to find out if a procedure exists or not. Previously I worked in Progress 4GL where such a thing is simple. I find it a valuable feature since it enables me to write general window-driving code where named local procedures (living inside a window) act as a hook to customize generic behaviour. I find it strange that in Windev I can enumerate just about anything living in a window, but not its local procedures.

Quote
Piet van Zanten
Of course this needs some extra adaptations that you probably want to avoid. However, it will make your code less vulnarable for future changes in Windev

You are right. I do want to avoid these adaptations, and I agree it will make my code more upwards compatible. But I still think that what I am seeing cannot be described as `changed behaviour`. It is incorrect!

/sohan

Hi,

I submitted this issue to PC Soft, and they have recognized it as a bug. They have not decided yet whether it will be fixed in a patch, or in v13.

In the meanwhile, I came up with a workaround - for those who are interested.

In case of mismacthed number of parameters, Windev neglects to set the appropiate exception information, and instead the ExceptionInfo() function returns the values belonging to the previous exception. The very first time this happens, there *is* no previous exception, which leads to inconsistent behaviour. The workaround consists of forcing a (self-made) exception prior to the call, to ensure that there is always a previous exception available:

WHEN EXCEPTION IN
	ExceptionThrow(903,"Mismatched number of parameters")
DO
END

WHEN EXCEPTION IN
	ExecuteProcess(...)  // Call a procedure, possibly with the wrong number of parameters
DO
	sErrMesg = ExceptionInfo(errFullDetails)
ELSE
	sErrMesg = "No Exception"
END

Trace(sErrMesg)

This effectively replaces exception 1003 (which fails to be raised in WD12) with exception 903.

/sohan