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

Question

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

    if (this._PasswordStrengthRegularExpression != null)
    {
        this._PasswordStrengthRegularExpression = this._PasswordStrengthRegularExpression.Trim();
        if (this._PasswordStrengthRegularExpression.Length == 0)
        {
            goto Label_016C;
        }
        try
        {
            new Regex(this._PasswordStrengthRegularExpression);
            goto Label_016C;
        }
        catch (ArgumentException exception)
        {
            throw new ProviderException(exception.Message, exception);
        }
    }
    this._PasswordStrengthRegularExpression = string.Empty;
Label_016C:
    ... //Other stuff

I've heard all of the "thou shalt not use goto on fear of exile to hell for eternity" spiel. I always held MS coders in fairly high regard and while I may not have agreed with all of their decisions, I always respected their reasoning.

So - is there a good reason for code like this that I'm missing? Was this code extract just put together by an inept developer? or is .NET reflector returning inaccurate code?

I'm hoping there is a good reason, and I'm just blindly missing it.

Thanks for everyone's input

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

Its probably not in the source code, that's just how the disassembled code looks.

Answer 3

I have seen goto used to break out of nested loops:

How can I break out of two nested for loops in Objective-C?

I don't see anything wrong with using it that way.

Answer 4

I never even coded with GO TO back when I wrote FORTRAN.

I've never had to use it. I can't see why any modern language would demand such a thing from a user. I'd say unequivocally "no".

Answer 5

As other's have shown the code you see in reflector is necessarily the code that is written in the Framework. The compiler and optimizers can change code around to something that functions in a similar manner as long as it does not change the actual work done by the code. It should also be stated that the compiler implements all branches and loops as goto's (branches in IL, or jumps in assembly.) When the release mode is ran and the compiler tries to optimizes code to the simplest form that is functionally the same as your source.

I have an example on different looping techniques that are all compiled to 100% the same IL when you compile for release. See Other Answer

(I can't find it right now but Eric Lippert posted an note on how the C# compiler processes code. One of the points he made is how all loops are changed to goto's.)

That being said, I have no problem with goto. If there is a better looping structure, use it. But sometimes you need something slightly then what you can squeeze out of for, foreach, while, do/while but you don't wanted the added mess and pain that comes from method calls (why waste 5 plus lines to convert a nested for into recursive methods.)

Answer 6

With respect to this point:

So - is there a good reason for code like this that I'm missing? Was this code extract just put together by a shitty developer? or is .NET reflector returning inaccurate code?

I disagree with the premise that these are the only three possibilities.

Maybe it's true, as many others have suggested, that this simply isn't an accurate reflection of the real source code in the library. Regardless, we've all been guilty (well, I have, anyway) of writing code "the dirty way" for the purpose of:

1. Getting a feature implemented quickly
2. Fixing a bug quickly
3. Squeezing out a slight performance gain (sometimes with justification, sometimes not so much)
4. Some other reason that made sense at the time

That doesn't make someone a "shitty developer." Most guidelines such as "thou shalt not use goto" are mainly put in place to protect developers from themselves; they shouldn't be treated as a key for distinguishing between good and bad developers.

As an analogy, consider the simple rule many of us are taught in grade school English: never end a sentence with a preposition. This isn't a real rule; it's a guideline to help prevent people from saying things like, "Where's the car at?" It's important to understand this fact; once you start treating it like an actual rule, instead of a guideline, you'll find yourself "correcting" people for perfectly good sentences like "What are you afraid of?"

With this in mind, I'd be wary of any developer who called another developer "shitty" because he used goto.

I'm certainly not trying to defend goto, per se--just arguing that its use doesn't indicate incompetence, by any means.