[fen4o]

Exactly. This led to the famous OSX double goto bug [0]

  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
  ... other checks ...
  fail:
    ... buffer frees (cleanups) ...
    return err;

[0] https://www.dwheeler.com/essays/apple-goto-fail.html

[SideburnsOfDoom]

The "Avoid Else, Return Early" blog post above appears to be about JavasScript code, which (along with Java, C#, Python, Ruby etc) do not ready do "buffer frees (cleanups)" much. They have other language and runtime mechanisms for this such as GC and try...finally blocks, which work fine with early return.

Yes, in the presence of teardown code at the end of the method, as is common idiom in C, avoid early return. This appears to be the case for apple's "goto fail" code.

However, don't generalise this to all languages.

[gkya]

I don't really understand why the use of goto is to blame there. If it was not a double goto but a double return, that'd still lead to this bug, no?

[DougBTX]

The goto fail snippet doesn't conform to the "one logical statement per line" guideline in the article though, so the author would advise against this style too.

[dep_b]

`goto` wouldn't be used in a return early philosophy.

[wildmusings]

Goto is heavily used to return early, by jumping to the cleanup section at the bottom of the function. Otherwise, you have to repeat the cleanup code at each exit point, or use the dreaded pyramid of doom where each failure point introduces another indent level, which is what the author here is trying to avoid in the first place.

[dep_b]

Not a C-programmer at all but I would separate out the resource creation/access from acting on the resource. So Open X, Do Y on X, Close X would have do Y on X in a separate function and possibly Open X and Close X as well. This way Close X would be executed regardless of the result of Do Y on X.

Only by doing multiple things in one function you really need to use goto's in C. (again, as far I can judge coding in C, not an expert!)

[SideburnsOfDoom]

"cleanup section at the bottom of the function" is pretty rare in JavaScript, which is what the original blog post is discussing. Same with Java, C#, Ruby etc.

No, it doesn't play well with early return, so avoid mixing them.

[vidarh]

Actually, in Ruby we have "ensure"

    def foo arg
      return true if arg == 42
      puts "got past the guard"
      raise "blah"
    ensure
      puts "ensure always"
    end
    
    foo(42)
    foo(3)

The "ensure" blocks gets executed whether or not you return early, throw exception or return at the end of the block.

[SideburnsOfDoom]

There are several constructs for it, see also "try ... finally" on C# and Java, and "using" statements in C#.

All make the "goto manual cleanup at end" less necessary, and make early return easier to use.

[wildmusings]

I should have specified that I was talking about C. You usually don’t need this pattern when you have garbage collection or C++ RAII.