Is there ever a reason to use goto in modern .NET code?

Question

I just found this code in reflector in the .NET base libraries...

    if (this._PasswordStrengthRegularExpression != null)
    {
        this._PasswordStreng         


        

Answer 1

In addition to all of these nice valid things, when you are looking at disassembled code keep in mind that the developers COULD have used an obfuscator on those assemblies. One technique of obfuscation is adding random goto's to the IL

Answer 2

There are several valid uses for goto in .NET (C# specifically):

Simulating Switch Statement Fall-through Semantics.

Those coming from a C++ background are used to writing switch statements which automatically fall-through from case to case unless explicitly terminated with break. For C#, only trivial (empty) cases fall-through.

For example, in C++

int i = 1;
switch (i)
{
case 1:
  printf ("Case 1\r\n");
case 2:
  printf ("Case 2\r\n");
default:
  printf ("Default Case\r\n");
  break;
}

In this C++ code the output is:

Case 1
Case 2
Default Case

Here is similar C# code:

int i = 1;
switch (i)
{
case 1:
  Console.Writeline ("Case 1");
case 2:
  Console.Writeline ("Case 2");
default:
  Console.Writeline ("Default Case");
  break;
}

As written, this will not compile. There are several compilation errors that look like this:

Control cannot fall through from one case label ('case 1:') to another

Adding goto statements make it work:

int i = 1;
switch (i)
{
case 1:
    Console.WriteLine ("Case 1");
    goto case 2;
case 2:
    Console.WriteLine("Case 2");
    goto default;
default:
    Console.WriteLine("Default Case");
    break;
}

... the other useful goto use in C# is...

Infinite Loops and Unrolled Recursion

I won't got into detail here since it is less useful, but occasionally we write infinite loops using while(true) constructs that are explicitly terminated with a break or re-executed with a continue statement. This might happen when we are trying to simulate recursive method calls but don't have any control over the potential scope of the recursion.

You can obviously refactor that into a while(true) loop or refactor it into a separate method, but also using a label and a goto statement works.

This use of goto is more debatable, but still something worth keeping in your mind as an option in very rare circumstances.

Answer 3

No, there's no good reason to use goto. I last coded a goto statement in 1981, and I haven't missed that particular construct since.

Answer 4

I have not seen a valid case for Goto in many, many lines of .NET code both written and reviewed.

In languages that do not support structured exception handling with a finally block (PASCAL - a grandfather of structured programming languages, as well as classic C come to mind), tactical use of a GOTO could lead to much easier to understand code when used to perform cleanup when execution terminated inside nested loops (as opposed to correctly setting multiple loop termination conditions). Even back in the day, I did not use goto personally for that reason (probably for fear of "exile to hell eternally").

Answer 5

I'm not crazy about gotos, but to say that they're never valid is silly.

I used one once to fix a defect in a particularly messy piece of code. To refactor the code and test it would not have been practical given the time constraint.

Besides, haven't we all seen conditional constructs that were so poorly coded that they make gotos seem benign?

Answer 6

I don't like that code.

I would prefer to store the Regex in the member, and validate it when setting it, avoiding all of the need for logic when reading it.