每个人都知道Dijkstra的《致编辑的信》:goto语句被认为是有害的(这里。html transcript和这里。pdf)，从那时起，就有一种强大的推动力，尽可能避免使用goto语句。虽然可以使用goto来生成不可维护的、庞大的代码，但它仍然存在于现代编程语言中。即使Scheme中先进的连续控制结构也可以被描述为复杂的后向。
在什么情况下需要使用goto?什么时候最好避免?
作为一个后续问题:C提供了一对函数setjmp()和longjmp()，它们不仅提供了在当前堆栈帧内进行跳转的能力，还提供了在任何调用帧内进行跳转的能力。这些应该被认为和goto一样危险吗?更危险?
Dijkstra自己也对这个头衔感到后悔，因为这不是他的责任。在EWD1308的结尾(也在这里。pdf)，他写道:
Finally a short story for the record.
In 1968, the Communications of the ACM
published a text of mine under the
title "The goto statement considered
harmful", which in later years would
be most frequently referenced,
regrettably, however, often by authors
who had seen no more of it than its
title, which became a cornerstone of
my fame by becoming a template: we
would see all sorts of articles under
the title "X considered harmful" for
almost any X, including one titled
"Dijkstra considered harmful". But
what had happened? I had submitted a
paper under the title "A case against
the goto statement", which, in order
to speed up its publication, the
editor had changed into a "letter to
the Editor", and in the process he had
given it a new title of his own
invention! The editor was Niklaus
Wirth.
Donald E. Knuth写了一篇关于这个主题的经典论文，它与Dijkstra的论文相匹配，那就是结构化编程与语句。阅读既有助于重建上下文，也有助于对主题的非教条性理解。在本文中，Dijkstra对这个案例的观点被报道，并且更加强烈:
Donald E. Knuth:我相信通过呈现这样一个
事实上，我并不是不同意
Dijkstra的观点，因为
他最近写道:
“请不要落入。
相信我是可怕的
教条的关于[去]的教条的
声明)。我觉得很不舒服
感觉别人在做
宗教出来了，好像
编程的概念问题
只用一个小技巧就能解决，用什么
一种简单的编码纪律!”
后藤认为他很有帮助。
我从1975年开始编程。对于20世纪70年代的程序员来说，“goto被认为是有害的”这个词或多或少地表明，具有现代控制结构的新编程语言值得一试。我们确实尝试了新的语言。我们很快就皈依了。我们再也没有回去过。
我们再也没有回去过，但是，如果你更年轻，那么你就从来没有去过那里。
现在，拥有古老编程语言的背景可能并没有太大用处，除非它能显示程序员的年龄。尽管如此，年轻的程序员缺乏这方面的背景，所以他们不再理解口号“goto被认为是有害的”在引入时向目标受众传达的信息。
一个人不理解的口号是不太有启发性的。也许最好忘记这些口号。这样的口号无济于事。
然而，这个特别的口号，“后藤有害”，已经有了它自己的不死生命。
能去不被虐待吗?回答:当然，但那又怎样?实际上，每一个编程元素都可能被滥用。例如，普通bool被滥用的次数比我们中的一些人愿意相信的要多。
相比之下，自1990年以来，我不记得遇到过一次真正的goto滥用案例。
goto最大的问题可能不是技术问题，而是社交问题。不太懂的程序员有时似乎觉得不赞成goto会让他们听起来很聪明。您可能需要不时地满足这样的程序员。生活就是这样。
今天goto最糟糕的事情是它没有被充分使用。
c++包含构造函数和析构函数。这允许一种称为RAII(资源分配是初始化)的模式。基本上，您创建一个本地堆栈变量，创建堆栈变量的行为打开一个文件，分配内存，锁定一个互斥锁，或以其他方式获取一个稍后必须释放的资源。
当变量超出作用域时，析构函数将运行并释放资源。
C语言没有这个特性。但您仍然经常需要在函数开始时获取资源，并在结束时释放它们。
你的函数可能有一个或多个错误条件导致它提前返回。您不希望重复资源释放代码。解决方案是使用goto。
例子:
int
foo(const char *arg)
{
char *argcopy = strdup(arg);
if (!isvalid(argcopy))
goto out1;
FILE *myfile = fopen(argcopy, "r");
if (myfile == NULL)
goto out1;
char bytes[10];
if (fread(bytes, sizeof(bytes), 1, myfile) != sizeof(mybytes))
goto out2;
/* do some actual work */
/* .... */
/* end of actual work */
out2:
fclose(myfile);
out1:
free(argcopy);
return 0;
}
Since I began doing a few things in the linux kernel, gotos don't bother me so much as they once did. At first I was sort of horrified to see they (kernel guys) added gotos into my code. I've since become accustomed to the use of gotos, in some limited contexts, and will now occasionally use them myself. Typically, it's a goto that jumps to the end of a function to do some kind of cleanup and bail out, rather than duplicating that same cleanup and bailout in several places in the function. And typically, it's not something large enough to hand off to another function -- e.g. freeing some locally (k)malloc'ed variables is a typical case.
I've written code that used setjmp/longjmp only once. It was in a MIDI drum sequencer program. Playback happened in a separate process from all user interaction, and the playback process used shared memory with the UI process to get the limited info it needed to do the playback. When the user wanted to stop playback, the playback process just did a longjmp "back to the beginning" to start over, rather than some complicated unwinding of wherever it happened to be executing when the user wanted it to stop. It worked great, was simple, and I never had any problems or bugs related to it in that instance.
Setjmp /longjmp有它们自己的位置——但那个位置是你不太可能只在很长一段时间内访问一次的地方。
编辑:我只是看了一下代码。实际上，我使用的是siglongjmp()，而不是longjmp(不是说这是一个大问题，但我已经忘记了siglongjmp的存在。)
