Other Languages - programming foundamental - Asked By Hafiz Ullah on 23-Nov-11 10:13 AM

Short definition with Example.
Q :-why it prohibited to goto statement.
aneesa replied to Hafiz Ullah on 23-Nov-11 10:37 AM

when (not) to use the goto keyword


This article discusses some common usage scenarios of the goto keyword and shows alternative approaches.

 

goto comic from xkcd.com

comic by xkcd.com ^


If someone would have asked me a few years ago when to use the goto keyword I would have answered (in capital letters): NEVER!! GOTO’S ARE EVIL! (and obviously you get attacked by raptors if you use them)

Like many I have been educated to have a emotional reaction when someone mentions the goto keyword. Emotions have nothing to do with good practices, so lets take a pragmatic look on some of the common usages of goto and see what the real value of the goto keyword is.

Using goto to provide a single exit point.

The author of Sams Teach Yourself C# in 24 Hours (published by O’Reilly) describes the usage of gotos like this: (code slightly modified to make it more readable)

[...]This discussion may leave you wondering why you would ever use goto. One situation in which I commonly use goto’s is to create single exit points. As you know, you can force execution to leave a method at any time using return. Often, clean-up code is required before a method exits. In a long method, you may have many return statements. However, such a method can be a problem to debug because clean-up code may not be run under all circumstances. Because all methods have a single entry point, it makes sense to give them a single exit point. With a single exit point, you use a goto statement to go to the exit point, rather than use a return statement. The following procedure illustrates using goto to create a single exit point:

private void btnGoto_Click(object sender, System.EventArgs e)
{
//...
// If it is necessary to exit the code, perform a goto to
// the PROC_EXIT label, rather than using an Exit statement.
if (someValue)
goto PROC_EXIT;
//...

PROC_EXIT:
//...
return;
}

The author suggests using gotos for cleanup code and to provide a single exit point. This seems logical and it might be the most common use of gotos, it is however in C# absolutely unnecessary. (I guess if someone wants to learn C# in 24 hours there is no time to learn it the ‘right’ way.) To force cleanup code we can and should use a simple try - finally pattern (read more about it in my article).

We can rewrite the code above to this

private void btnGoto_Click(object sender, System.EventArgs e)
{
//...
try
{
//... (can even contain return statements or throw Exceptions)
}
finally
{
//cleanup here
}
}

This approach has two major advantages:

  1. you don’t have to remember to use goto instead of return

  2. the cleanup code is executed even if there is an exception thrown

Using goto to jump between switch statements.

Coming up with a reasonable example for a goto in a switch statement has proven to be difficult, which in itself might be an indicator for its usefulness. Anyway, basically you can jump from one case in a switch code block to another using the goto statement.

switch (something)
{
case 1:
//some code
goto case 2;
case 2:
//some code
if (someExpression)
goto case 1;
//some more code
goto case 4;
case 3:
//some code
break;
case 4:
//some code
goto default;
default:
break;
}

Let’s just take a look at this code snippet to discuss some of the upsides and downsides of goto statements in a switch code block. One good thing with labels in the switch statements (case 1, case 2 ect.) is that they are only accessible within the scope of the switch statement, which means that you cannot jump into the switch statement. This makes it easier to read but as you can see in the example above it makes it more complicated to follow the execution since it is no longer linear. Especially if the switch block is longer than a page and you use conditional goto’s (such as the one in the if (someExpression) block) it can be a real challenge to follow the execution flow. Unfortunately there is nothing to prevent you from defining a loop in which case the program will cause a StackOverFlowException. In the example above the goto case 1 in case 2 sends it back to case 2 and it could potentially be send back to case 1 again creating a loop. I would suggest to be open for the usage of the goto statement in switch blocks unlesst he complexity is high enough to make it painful to debug or there are possibilities for loops.

Using goto to break out of nested loops.

Another popular usage of gotos is breaking from nested loops. Unfortunately there is no break all keyword that would help us to break out of nested loops so we have to find another way of doing this.

for (int i = 0; i < 25; i++)
{
for (int j = 0; j < 25; j++)
{
if (j == 4)
goto exitLoop;
//...
}
}

exitLoop:
//cleanup
return;

As long as the exitLoop label is immediately after the loop there is little chance that anything goes wrong here thus I think it is quite okay to use goto this way but you can also use a bool variable to achieve the same.

bool breakAll;
for (int i = 0; i < 25; i++)
{
for (int j = 0; j < 25; j++)
{
if (j == 4)
{
breakAll = true;
break;
}
//...
}
if (breakAll)
break;
}

The later has the disadvantage that you have to remember to check for the breakAll variable in every loop. A better option in my opinion is to refactor the nested loops into a single method where you can use the return statement in order to break out of them.

So, when do you use goto’s?

I didn’t have to use a single goto statement in production code myself but I can see some situations where it might be efficient to use one. I guess the reason why I am not using it is because most of the time there is a better or equal alternative and I am one of these developers who enjoys refactoring/improving code which means that if I have to chose between ‘refactor the program flow’ or ‘use this one little goto statement’ it is highly likely that I will do the former. (and that has nothing to do with my fear of raptors)

Riley K replied to Hafiz Ullah on 23-Nov-11 10:46 AM


don't  post  the same question multiple times
Suchit shah replied to Hafiz Ullah on 23-Nov-11 11:10 AM

The following statements are generalizations; while it is always possible to plead exception, it usually (in my experience and humble opinion) isn't worth the risks.

  1. Unconstrained use of memory addresses (either GOTO or raw pointers) provides too many opportunities to make easily avoidable mistakes.
  2. The more ways there are to arrive at a particular "location" in the code, the less confident one can be about what the state of the system is at that point. (See below.)
  3. Structured programming IMHO is less about "avoiding GOTOs" and more about making the structure of the code match the structure of the data. For example, a repeating data structure (e.g. array, sequential file, etc.) is naturally processed by a repeated unit of code. Having built-in structures (e.g. while, for, until, for-each, etc.) allows the programmer to avoid the tedium of repeating the same cliched code patterns.
  4. Even if GOTO is low-level implementation detail (not always the case!) it's below the level that the programmer should be thinking. How many programmers balance their personal checkbooks in raw binary? How many programmers worry about which sector on the disk contains a particular record, instead of just providing a key to a database engine (and how many ways could things go wrong if we really wrote all of our programs in terms of physical disk sectors?

Footnotes to the above:

Re point 2, consider the following code:

a = b + 1
/* do something with a */

At the "do something" point in the code, we can state with high confidence that a is greater than b. (Yes, I'm ignoring the possibility of untrapped integer overflow. Let's not bog down a simple example.)

On the other hand, if the code had read this way:

...
goto 10
...
a = b + 1
10: /* do something with a */
...
goto 10
...

The multiplicity of ways to get to label 10 means that we have to work much harder to be confident about the relationships between a and b at that point. (In fact, in the general case it's undecideable!)

Re point 4, the whole notion of "going someplace" in the code is just a metaphor. Nothing is really "going" anywhere inside the CPU except electrons and photons (for the waste heat). Sometimes we give up a metaphor for another, more useful, one. I recall encountering (a few decades ago!) a language where

if (some condition) {
  action-1
} else {
  action-2
}

was implemented on a virtual machine by compiling action-1 and action-2 as out-of-line parameterless routines, then using a single two-argument VM opcode which used the boolean value of the condition to invoke one or the other. The concept was simply "choose what to invoke now" rather than "go here or go there". Again, just a change of metaphor.

Jitendra Faye replied to Hafiz Ullah on 23-Nov-11 10:59 PM

Disadvantages of Goto
 
Goto should not really be used in programs at . They have a tendancy to make code unstructured and they make programs difficult to manage when they become significantly large.

 

It is much better practice to use the other flow control constructs and procedures.