# Sub/EndSub and Goto Logic

• ### Question

• I'm having difficulty understanding the logic between Sub/EndSub statements and hope someone can set me straight.  I've done the following to try and make the logic clear to me but it doesn't help.

Line_A()

Sub Line_A
F = 10
IF F = 0 Then
GOTO Line1
Else
Goto Line2
EndIf

Line1:
TextWindow.WriteLine("This is the text in the Sub/EndSub flow")
EndSub

Line2:
TextWindow.WriteLine("This is the text outside of the Sub/EndSub flow")

With F = 10 the text at Line1: shouldn't show on screen but it does and then the Line2: text shows.

I simply cannot see what is happening.  I can only assume it has something to do with having a Goto inside a Sub/EndSub construct.

Chris

Sunday, June 16, 2013 7:05 AM

• Keyword Goto wasn't meant to leap in amongst Sub..EndSub blocks!

Actually, Sub blocks are the real deal that makes Goto outta place for such block controlling!

Still, Goto is useful to make infinite loops, get out prematurely from a loop

and skip a mini-block section for some special condition.

However, use Goto as few as possible, lest you might end up w/ a "spaghetti" code for abusing it!

Click on "Propose As Answer" if some post solves your problem or "Vote As Helpful" if some post has been useful to you! (^_^)

Sunday, June 16, 2013 7:53 AM
• For some good basics on branching and program flow and using GOTO's and Subroutines check this article by litdev:

Sunday, June 16, 2013 9:23 AM
• The gotos in the subroutine Line_A cannot jump to labels outside its Sub/EndSub clause.. Since Line2: exists outside of the subroutine, when it tries to execute the goto Line2, it doesn't find it, and basically ignores the jump. It then continues out of the if/endif clause and executes the rest of the subroutine, which is the label Line1: and the Textwindow.writeline immediately following it.

Once the subroutine has completed, it exits and then continues on to the next statements in your program which are the label Line2: and the writeline immediately following.

Basically, both writelines will be executed no matter what branch is chosen.

Hope that helps!

Wednesday, June 19, 2013 3:12 AM

### All replies

• To check what is happening in your code I have just added two lines in your code and it is working as per your expectation. Code with added line ( Shown in bold face) is as below at it is now working as per your expectation.

Line_A()

Sub Line_A

F = 10

IF F = 0 Then

GOTO Line1

Else

Goto Line2

EndIf

Line1:

TextWindow.WriteLine("This is the text in the Sub/EndSub flow")

TextWindow.Pause()

EndSub

Program.End()

Line2:

TextWindow.WriteLine("This is the text outside of the Sub/EndSub flow")

Actually what is happening in your code is that, SB programmng is procedural like programming i.e. top down logic flow unless we wont make it event driven thus –

1. Your program is calling Sub Line_A
2. Then through that sub it is going to Line1 label
3. Again it is coming back to calling sub as calling sub does not encountered the EndSub statement
4. After encountering EndSub statement program happens to be continued and executing instruction under Line2 label
5. Hence you are getting both lines printed

What I have done here is that –

I have ended the program forcely using statement Program.End() after complition of execution of Sub Line_A

And posued in text window after executing statement under Line1 label

Sunday, June 16, 2013 7:38 AM
• Keyword Goto wasn't meant to leap in amongst Sub..EndSub blocks!

Actually, Sub blocks are the real deal that makes Goto outta place for such block controlling!

Still, Goto is useful to make infinite loops, get out prematurely from a loop

and skip a mini-block section for some special condition.

However, use Goto as few as possible, lest you might end up w/ a "spaghetti" code for abusing it!

Click on "Propose As Answer" if some post solves your problem or "Vote As Helpful" if some post has been useful to you! (^_^)

Sunday, June 16, 2013 7:53 AM
• For some good basics on branching and program flow and using GOTO's and Subroutines check this article by litdev:

Sunday, June 16, 2013 9:23 AM
• The gotos in the subroutine Line_A cannot jump to labels outside its Sub/EndSub clause.. Since Line2: exists outside of the subroutine, when it tries to execute the goto Line2, it doesn't find it, and basically ignores the jump. It then continues out of the if/endif clause and executes the rest of the subroutine, which is the label Line1: and the Textwindow.writeline immediately following it.

Once the subroutine has completed, it exits and then continues on to the next statements in your program which are the label Line2: and the writeline immediately following.

Basically, both writelines will be executed no matter what branch is chosen.

Hope that helps!

Wednesday, June 19, 2013 3:12 AM
• Thank you to everyone who has replied.  Clearly never place a Goto into a Sub if at all possible.

To try and close this matter I would like to know:-

A.  Is it good practice to have Goto point into a Subroutine?

B. Is it Ok to have a Goto that stays wholly within a Subroutine?

C.  When you have a program that does have Goto's within a Sub and they direct the program flow out of the Sub is there a best practice for removing the Goto's but still getting the same outcomes.  The answer is probably to re-do the logic but I'd like a few opinions.

Regards,

Wednesday, June 19, 2013 11:46 AM
• A: You can't enter a Sub. You can only call it.

B: Yes. It's best if the goto is close to the label it's pointing to.

C: You can't target a label outside a Sub using goto. You can call a sub another sub.

I reckon goto's should be avoided and try to use conditional branching or calling a sub. They can be handy for exiting a loop or pointing to a nearby label.

The main thing is that you don't want your code pointing all over the place. It's easier to follow when conditions are being tested or routines are being called. That way when you read the code it's following the logic of conditions and loops and the calling of routines that run their course. And not the discretionary compass of a Goto.

Wednesday, June 19, 2013 12:30 PM