Exiting from GOSUB routine without RETURN

[Bern Ertl]

I've got a chunk of code in a callback function that I want to move to a GOSUB block as it's used about 10 times in different places.

Part of the code has error handling that should either exit from the function or close the associated dialog. In these cases, I'd like to go ahead and do what's required from the GOSUB block.

To maintain stack integrity, I just need to !pop a LONG/DWORD value, right? Ie. something like this:

IF <errorcondition> THEN
   !pop lReturnAddress
   DIALOG END CB.HNDL, 0
   EXIT FUNCTION
END IF

[Paul Dixon]

Bern,
see this:

http://www.powerbasic.com/support/pbforums/showpost.php?p=284549&postcount=18

Paul.

[Mel Bishop]

...used about 10 times...

Without knowing the specifics of your app structure, have you considered placing the used 10x code in a single SUB/FUNCTION?

You know, if you use the same routine 10 times, it only makes sense to put it there and the call it x number of times.

[Bern Ertl]

Thanks Paul. It feels like jumping out of an airplane without a parachute not to balance the stack myself though.

[Eric Cochran]

Without knowing the specifics of your app structure, have you considered placing the used 10x code in a single SUB/FUNCTION?

It could be done that way, yes, but the beauty of GOSUB lies in that it accomplishes the same thing without incurring the overhead of setting up a stack frame. GOSUB is the more efficient way of calling a SUB with no parameters, although it's not likely that the added efficiency will really be noticed outside of highly trafficked code.

[Michael Mattias]

To maintain stack integrity [in GOSUB block], I just need to !pop a LONG/DWORD value, right? Ie.

Wrong. You need to execute a RETURN, just like it says in doc following GOSUB.

If you get yourself into an errorhandler , just set up a label and RESUME there.

e.g.

MySubroutine:
   ON ERROR GOTO ERRORTRAP 
   yadda
   yadda
   yadda

MySubroutine_Exit: 
  IF Flag_var THEN 
      whatever
  END IF
  RETURN 

ErrorTrap:
  'Show bad things here and/or set a flag variable 
  'so you know what to do when you get back
  RESUME  MySubroutine_Exit

MCM

[Mike Doty]

Not wrong. It could be done without the RETURN.
Thanks Paul for the link to Mr. Zale's explanation.
It appears EXIT FUNCTION will clean up the stack..

http://www.powerbasic.com/support/pbforums/showpost.php?p=284549&postcount=18

[Michael Mattias]

>Not wrong. It [exiting GOSUB block] could be done without the RETURN

OK, fine. Let's just call it "technique." Technique is judged subjectively. This techinque stinks.

> Thanks Paul for the link to Mr. Zale's explanation.

Mr. Zale's explanation in subject link is not about exiting a GOSUB block, it's about exiting a PROCEDURE. Procedures are not the same as subroutines.

Maybe we should all just go back to the days before there were procedures OR subroutines... nothing like a raft of GOTOs to make maintenance programming a sheer pleasure.

MCM

[Scott Slater]

I understand that GOSUB, ON GOTO/GOSUB are there for BASIC compatibility but don't really see the need for them when writing NEW code. I avoid these completely. I also do my best to completely avoid GOTOs, but sometimes you have to break down and use one.

[Michael Mattias]

Oh, don't mind me.

I am just ranting about taking shortcuts or trying the "game the system" when all it takes to create working, supportable, maintainable, portable code is a little effort.

[John Gleason]

from Scott Slater: I understand that GOSUB, ON GOTO/GOSUB are there for BASIC compatibility but don't really see the need for them when writing NEW code.

Sometimes there can be a need even in new code. From the PowerBasic docs it says:

For time critical or high-performance code, using a GOSUB to perform a repetitive task is almost always faster then performing a call to a procedure, since there is no overhead in setting up a stack frame for a GOSUB.

A macro can even be more efficient, but the above doc points out an advantage that becomes even more important if a lot of parameters are involved.

[Scott Slater]

I agree that they are faster than calling a SUB/FUNCTION, but this would more than likely occur in very rare occasions. As stated, a MACRO could be used, but you could also use other structures such as IF/THEN or SELECT/CASE blocks and various LOOPing structures without calling a SUB or FUNCTION.

I guess this is more of a personal preference, and is not meant to bash GOSUBs etc. or anybody's programming styles. I just wondered why they would be used since it is my personal opinion that it is a little harder to maintain code that has lots of them. Since programming is an art, there are many ways to accomplish the same task. I personally prefer inline ASM or pointer-driven code for sections that need to perform with maximum speed (which is very easy with PowerBASIC), and do my best to avoid GOSUBs. GOTOs on the other hand sometimes cannot be avoided {grin} and I cringe when I have to use one...

[Michael Mattias]

it is my personal opinion that it is a little harder to maintain code that has lots of [subroutines]..

I'd agree with that.

Sometimes I wonder how much "weight" is given to "maintainability" when making the tradeoffs which must be made between speed, resource utilization, features, etc.

I know I give maintainability a LOT of weight, since I don't ever recall seeing program which was not changed later.

I figure it costs about ten percent to make the program maintainable versus just pounding it in to "get it done." I also figure the first time you have to so much as touch that program for maintenance you have your investment back with a profit.

MCM

[Richard Angell]

"I just wondered why they would be used since it is my personal opinion that it is a little harder to maintain code that has lots of them."

There is also the euphemistic, academic's approach that says a Sub or Function that takes more than a printed page is too long and hard to maintain the code in too. Of course trying to do that in practice is often a bit more difficult than classroom examples. The same academic mindset has often put down GOSUB and GOTO. Perhaps these folks ought to spend a few years at hard assembler coding, they might see why GOSUB and GOTO are such efficient tools! If GOSUB and GOTO are used correctly as well as judiciously they can be beneficial and maintainable. Just because the Code Finder doe not list them does not mean they can not be used. (BTW I made an NFS that the Code Finder have a context menu selector for labels in listed functions so we could use it to jump to the code)

What is really missing is that there is no hard and fast guideline in higher level languages as to when using these tools would be good to consider as alternatives versus blasting away with a plethora of Subs and Functions. The only true reality is that code can be difficult to maintain wherever it is, if it is not commented well or if it is made so convoluted not even the originator can see what was intended when trying to maintain it some time later. So the real alternative is to develop and practice coding habits that help keep any code maintainable in the future. Yes, I know, easy to say, harder to do ... and many of us must plead guilty at times.

By practice though , I always place an EXIT FUNCTION or EXIT SUB before any GOSUB code blocks in a function. Then, by general practice, I usually will enter the GOSUB label, then a couple of blank lines, then the RETURN line. This avoids a lot of problems here as with any block like structure (e.g. IF,SELECT,DO, etc.) In a current app these GOSUBS are called a significant number of times, far more than just 10 mentioned here. They use a significant number of local parameters as well, so time is definitely saved. Relevant code is kept together. However, I also have defined subs or functions of other repetitive code where the parameters passed are few. Sometimes a code segment starts as a GOSUB, but then later I decide that it will have more use outside of the current function, so I encapsulate it in a sub or function. In those cases the GOSUB helped the development moce along rather quickly, but when another use outside the function was mandated, moving from the GOSUB to a sub or function was easy enough and replacing the GOSUB label lines with a sub or function calls was dirt simple with find and replace session with the original function.

GOTO's are quite useful when the code identifies the need to exit the function before further data processing, but still needs to terminate some open handles, etc. before exiting the routine, For example, a current program may have an open record set, as well as an open connection. In this case, though not all possible cases for other code situations, the GOTO just jumps to the normal exit portion of the code lines in the particular function.

GOTO's can also be quite useful for some situations where you need to repeat a section of code in response to some determined condition, but which would not normally be in a looping structure such as it's own FOR, DOW, WHILE, etc. In this situation it is like an ITERATE ... but at this label.

All said though, these are tools, Power Tools, so be careful not to get hurt using them

[Rodney Hicks]

Very well articulated Richard, much better than the response that I was working on, but of similar vein.

[Michael Mattias]

Actually, GOSUBs are not all bad. It's the multiple RETURNs within a subroutine which are the real killers.

[Richard Angell]

Well, did he the GOSUB ever return? No, he it never returned and his its fate is still unknown. (What a pity! Poor ole Charlie. programmer Shame and scandal. He The GOSUB may ride error forever. Just like Paul Revere.) He he GOSUB may ride err forever 'neath the streets of Boston program code. He's the man Its the GOSUB who which never returned.

A la Kingston Trio's MTA ballad ... inspired by "It's the multiple RETURNs within a subroutine which are the real killers."

Multiple RETURNs are not abnormal programming anomalies at all. In programming we all have an onus to understand where we or going when we branch a progam, whether to a separate sub or function, a goto or gosub. Just because in BASIC we terminate a sub or function with END SUB or END FUNCTION, or pre-emptively leave with an EXIT SUB or EXIT FUNCTION, all we are really doing most of the time is using a particular BASIC substitute for what is actually a RETURN to the calling routine. Although in these cases we have opted for a variety of reasons to accept the overhead of the stack fram need to access this code routine.

There even programming languages out there in the wild that do not use end statements ... but use RETURN , e.g JAVA method (function) Return value Also there is Assembler which has several mnemonic forms of RETURN, RET as wel as RETF and RETN. What is more probable is that not using a tool can make one unfamiliar with "safe practice" while using it. A few bad experiences can unfortunately wipe out a plethora of good ones.

[Michael Mattias]

>A la Kingston Trio's MTA ballad

Woo. You are showing the number of candles on your last birthday cake.

I know Glenn Yarborough died a long time ago (20 years?) and I'd go even money that at least one of the other two has joined him.


MCM

[Richard Angell]

Who Died ...?

http://en.wikipedia.org/wiki/Glenn_Yarborough

http://www.kingstontrio.com/html/home.htm

[Michael Mattias]

I have simply got to stop trusting my memory.

I shall start by adoping as my personal mantra, "Google, Google, Google!"