Return without a gosub

[Kenneth Brody]

(Sorry for lack of snippage, but there really isn't anything to strip.)

On 3/2/2011 9:24 AM, Richard Kreiss wrote:
>> -----Original Message-----
>> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
>> [mailto:filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com] On
>> Behalf Of Robert T. Repko (R Squared Consultants)
[...]
>> Believe it or not at 3/1/2011 10:46 PM, Richard Kreiss said:
>>> I have a routine that is activated by @keyA.
>>>
>>> It does some lookup before initiating the main portion of the routine
>>> with a gosub.
>>>
>>> The program executes a popup update-
>> ,"pop_memo",ad;clearP;clears;GOTO
>>> f_stat
>>>
>>> Once the screen opens with dummy fields, @wefad, @wlfad, at wefae and
>>> @wlfad occur.
>>>
>>> When the processing for the 2 fields ends, there is an input popup y,
>>> to confirm if the information entered is correct.  The information is
>>> then posted.
>>>
>>> The program hits a save and then executes the balance of the popup
>>> update line.  This ends with the GOTO f_stat.  (22 line of code)
>>>
>>> 1350: if:@keyA
>>>    Then: Return
>>>
>>> Here is the point my client called this afternoon saying he got a
>>> return with no gosub.
>>>
>>> Question: how many lines of code with some gotos before filePro loses
>>> track of a label used on the if line.
>>>
>>> I have tested this routine a number of time before today and have never
>>> gotten this error.
>>>
>>> This routine starts at line 346 and executes the GOSUB at line 360. The
>>> subroutine starts at 1324 and ends at 1350.
>>>
>>> The reason for the return here is that this same routine for adding a
>>> comment is also used from a browse lookup using @bk="A"
>>
>> It sounds as though you have a routine that is entered using goto and is
> also
>> entered using gosub:
>>
>> 'The reason for the return here is that this same routine for adding a
>> comment is also used from a browse lookup using @bk="A"'
>>
>> If that's the case then you would have to set a flag so you either 'end'
>> or 'return' based on how you entered the routine.
>
>
> You are correct except that I am using the @keyA on the if line as a flag
> for the return.

I think he saw that.  However, he was suggesting that "if: @keyA" was not a 
good way of testing the execution path.

> My problem is that this routine has been test by me and in use to 20 or so
> users at my client's site for the past few weeks without a problem.

So it's probably some obscure execution path which is being hit.

> Although this problem should not have occurred, I modified the program
> slightly.  I declared a long variable KeyA(1,*) and when @keyA executed the
> variable is set to "Y".
> Then line 1350 checks for KeyA="Y" and if true, does the return.

And I expect you will see the same "return without gosub" error should the 
same execution path be taken again.

> This should not have been necessary as labels have always been available for
> use on the if line to make setting conditions easy.

You are correct about the ability to test for the value of a label. 
However, that just means that @keyA is true even though you don't want a 
RETURN to be executed at this time.  You still haven't pointed out any 
problem with filePro or its "ability to keep track of labels".

Your change as described above won't change this behavior, since the 
variable KeyA will still hold "Y", just like @keyA is still "true".  I would 
recommend that you clear KeyA prior to the RETURN, so that when it hits it 
again, it won't take the RETURN.

And even that makes the assumption that it's always the first time through 
that you want the RETURN, and never the second (or third, or fourth, or...).


My recommendation is not never have a "sometimes I RETURN from a GOSUB, and 
sometimes I just END" scenario.  _Always_ have a subroutine finish with a 
RETURN.  If there are times when it's used as some standalone code which 
doesn't need the RETURN, then make the standalone code consist of just a 
GOSUB to the subroutine followed by an END.

-- 
Kenneth Brody