Code Focused

Tricks with Goto in Visual Basic and C#

Goto statements, whether they're used in Visual Basic or C#, can be confounding as to their purpose in some contexts.

The Goto statement in both Visual Basic and C# seems like an amazing tool for getting out of sticky code blocks. But it can also get you into sticky blocks, at least in Visual Basic. Consider this somewhat useless block of Visual Basic code:

Dim pass As Integer = 0
If (True) Then
  Dim passFactor As Integer = 5
ShowMessage:
  pass += 1
  MessageBox.Show($"Pass value = {pass * passFactor}")
End If
If (pass = 1) Then GoTo ShowMessage
MessageBox.Show("Finished")

This code will show three message boxes, the first two with pass values of 5 and 10, respectively, and then the "Finished" message. The GoTo statement returns back to the inner conditional block for a second chance at the message display, albeit with an updated pass value. But the results are somewhat different if you start out with a jump directly to the message portion of the code:

Dim pass As Integer = 0
GoTo ShowMessage ' <-- This is new!!!
If (True) Then
  Dim passFactor As Integer = 5
ShowMessage:
  pass += 1
  MessageBox.Show($"Pass value = {pass * passFactor}")
End If
If (pass = 1) Then GoTo ShowMessage
MessageBox.Show("Finished")

The updated code still shows three messages, but the first two messages display the text, "Pass value = 0," instead of the "5" and "10" versions of the original code. This change occurs because the GoTo statement jumps over the initialization of the passFactor variable, causing it to retain its default zero setting.

Keep in mind that although the GoTo statement jumped over the initialization of the passFactor variable, it didn't jump over the instantiation of that same variable. In Visual Basic, all local variables, even those scoped within a block (such as an If statement block) are created when the method begins and, therefore, have lifetimes that endure for the full duration of the method.

Although you cannot write code to access the passFactor variable outside of its containing If block, it still exists outside of that block, because it was brought into being outside of that block, as a part of the method's initialization process. This has the side effect of giving Visual Basic a lot of flexibility with its GoTo statements. Making a random jump into the middle of an If block is safe; you can access inner-scoped variables in that block, even if it appears that the GoTo statement bypassed the declaration of those scoped variables, like passFactor.

C# isn't so benevolent with its goto jumps. The equivalent and equally useless sample code, when converted to C#, will not compile:

int pass = 0;
if (true)
{
  int passFactor = 5;
ShowMessage:
  pass += 1;
  MessageBox.Show($"Pass value = {pass * passFactor}");
}
if (pass == 1)
  goto ShowMessage;
MessageBox.Show("Finished");

The error occurs with the goto statement. From its perspective, the ShowMessage label doesn't exist, because it appears in a different scope context. This restriction is necessary, in part, because of the way C# treats locally scoped variables.

While Visual Basic instantiates all local variables when a method first begins, C# instantiates inner-scoped variables (like passFactor) only when that inner scope is accessed by the code. In this case, jumping into the middle of the if block, especially after the passFactor declaration line, could enable access to uninitialized and even undeclared variables. To prevent such dangers, C# locks down goto jumps between certain scope contexts.

The solution, of course, is to restructure the code so that the cross-scope jump becomes unnecessary. Or to write code that does something useful. That would also be a solution.

About the Author

Tim Patrick has spent more than thirty years as a software architect and developer. His two most recent books on .NET development -- Start-to-Finish Visual C# 2015, and Start-to-Finish Visual Basic 2015 -- are available from http://owanipress.com. He blogs regularly at http://wellreadman.com.

comments powered by Disqus

Featured

  • VS Code Now Has Apple Silicon Builds for Native Mac Development

    Goodbye Rosetta, hello M1. Visual Studio Code has been updated with new builds that let it run natively on machines with Apple Silicon (M1), the company's own ARM64 chips.

  • Visual Studio 2019 for Mac v8.9 Ships with .NET 6 Preview 1 Support

    During its Ignite 2021 online event for IT pros and developers this week, Microsoft shipped Visual Studio 2019 for Mac v8.9, arriving with out-of-the-box support for .NET 6 Preview 1, which the company also released recently.

  • Analyst: TypeScript Now Firmly in Top 10 Echelon (Ruby, Not So Much)

    RedMonk analyst Stephen O'Grady believes TypeScript has achieved the rare feat of firmly ensconcing itself into the top 10 echelon of his ranking, now questioning how high it might go.

  • Black White Wave IMage

    Neural Regression Using PyTorch: Training

    The goal of a regression problem is to predict a single numeric value, for example, predicting the annual revenue of a new restaurant based on variables such as menu prices, number of tables, location and so on.

Upcoming Events