Comment Re:Never Use Goto (Score 1) 677
Then how do you cleanly handle a function that needs to acquire N resources where any one of the acquisitions can fail -- and it needs to clean itself up on failure (and possibly on success)?
The only non-goto answer I've seen so far is to have ever deeper nesting of if's (with a return buried in its depths if the resources should be held on success), followed by a bunch of unwinding else's that contain and separate the error handling in else's and far away from the error detection (with a different return path when the resources are held on success).
Such coding contains a bunch of anti-patterns: ArrowAntiPattern and rejects the use of GuardClauses and HandleErrorsInContext.
Meanwhile, the goto version does exactly the opposite -- it doesn't have ever deeper nesting of the common successful path, it uses guard clauses to abort further execution upon error detection, error dispatching (and any in context handling if necessary) is easily done and you can jump to exactly the right section of cleanup code and it is easy to have a single exit point for the function after all the cleanup code at the bottom of the function.