Gotos like that are fine. Despite the title of the paper I don't think Djikstra's meaning was that gotos should be removed entirely.
Like, imagine the spaghetti lovecraftian horror of a non trivial program that's just if and goto. At the time, there was a particularly vocal camp that essentially made the argument that it shouldn't matter since if/goto is equivalent to what exists in the machine code anyway, and you can technically do all the same things.
These things are hard to notice, and even harder to find elegant and effective solutions!
The point is to reduce the problem space so all you are left to look at, when you do come back to your code, is what's important to reason about without removing important details or adding trivialities. These problems haven't gone away just because the literal word goto isn't used anymore.
Such as?
I am aware of writing this in different ways, of architecting the logic quite differently. But the only control-flow construct I've seen as alternatives are to abuse exceptions or labelled while with named breaks.
What were you thinking of when you wrote this? I'm genuinely interested.
You can however give named return values and reference those names, and I believe it will work.
I've not seen any other constructs in any language that would come close, and I still maintain `goto fail` is a reasonable construct.
I'm actually not sure offhand how multiple deferred statements are handled. I could envision that the specification might make no explicit guarantee about the runtime order or it might create and pop off of a stack (at least in behavior).
Foo foo = acquireFoo()
defer releaseFoo(foo)
if !isValid(foo) {
return FAIL
}
moreWork(foo)
return SUCCESS
I agree, I am quite comfortable using goto in C/C++ in this context. Though it may be better in C++ to use RAII in this specific example.
(with-open-file (fhandle path)
(if (has-record fhandle)
(process-record (get-record fhandle))))
http://clhs.lisp.se/Body/m_w_open.htm
> If a new output file is being written, and control leaves abnormally, the file is aborted and the file system is left, so far as possible, as if the file had never been opened.
Shades of PCLSRing!
Python doesn't use macros, true. But it absolutely gives you the ability to do 'with' for other kinds of resource (and anything else). Look for the with-statement and documentation on defining your own context manager.
The ease of writing macros such as with-open-file means that most libraries that need to have similar types of features for their resources that needs releasing also provides similar functionality.
try {
doSomething();
}
catch (Exception e) {
handleException();
}
finally {
cleanUpResources();
}
Foo foo = acquireFoo();
try {
if (!isValid(foo)) {
return FAIL;
}
moreWork(foo);
return SUCCESS;
} finally {
releaseFoo(foo);
}
That there is no high-level equivalent, and Djikstra, while he sometimes had useful insights, was ultimately a self-righteous twit.
Sorry to disappoint; I would also be interested a (not-even-worse-than-goto-like-exceptions-are) answer to your question.
[0] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/E...
There's just too much cleanup, such that avoiding gotos means you're either nested 200 columns into the screen or have half your function filled with partially-duplicated cleanup code.
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...
There are ways to do early returns in C without duplicating resource releasing code though, using gotos (it's one of the few cases where gotos make sense, IMHO). Code looks like this:
The Linux kernel makes heavy use of this.