On Mon, 22 May 2017, Allin Cottrell wrote:
On Mon, 22 May 2017, Sven Schreiber wrote:
> Hi,
> I have the following strange behavior which was a bit difficult to track
> down. Sorry, cannot give a minimal example because the problem then doesn't
> appear. In my more complex setup it's reproducible, however.
>
> The trigger is a "var 0 endolist" command, which is invalid because the lag
> order isn't positive. (Actually it's "var km1 endolist; xlist
@somestring
> --silent", and km1 sometimes happens to be 0.)
> My first minor complaint is that here gretl's error message could be a bit
> more specific than just "invalid argument".
Ah, that was specific to giving a variable rather than a numerical value for
the lag order. Now fixed in git: either way you'll see
Invalid lag order 0
> OK, so I'm trying to use "catch", and immediately after the "catch
var"
> line I have:
>
> err = $error
> if err
> print err
> <...>
> endif
>
> But: Now gretl, instead of printing the err and so on, throws another error
> message "unpaired if" (re-translated from German). How can that be? That
> must be bogus, because gretl doesn't complain in all those cases where
> $error==0 (which happens most of the time; all this is inside a random
> simulation loop).
OK, not sure about that; I'll take a closer look.
I think I found the problem: on repeated errors in a loop, "catch"
could stop working (that is, fail fully to nullify the error
condition).
I show below an example which did not work properly before, but
which now does. Hopefully it exhibits the same problem as you found;
if so the issue is fixed in git.
<hansl>
open data9-7 -q
list L = QNC PRIME UNEMP
loop i=1..100 -q
scalar p = randgen1(u,0,1) < 0.2 ? 0 : 1
if p == 0
printf "iter %d, p = 0\n", i
endif
catch var p QNC PRIME UNEMP --silent
err = $error
if err
printf "Problem, err = %d\n", err
endif
print "Merrily on our way..."
endloop
</hansl>
Allin