GOTO 和 THROW 之间的区别？

Question

最近很多人指责我只提到一个词——“goto”。
这让我想知道，为什么它被认为是一个如此令人讨厌的词。
我知道之前关于该主题的一些讨论，但这并不能说服我 - 其中一些答案只是说“这很糟糕”，甚至没有试图解释，有些还带来了原因，与脚本语言，如 PHP、IMO。

无论如何，我要问一个非常具体的问题：
让我们比较一下 goto 和 throw 语句。
在我看来，两者都做同样的事情：根据某些条件避免执行某些部分的代码。
如果是这样 - throw 是否具有与 goto 相同的缺点？ （如果有的话）？
如果不是——那就有什么区别了。

经验丰富的人谁能说出以下两个代码片段的代码结构之间的根本概念差异？
关于这些代码片段，不是“理论上”或“一般来说”或“这是一个不错的 XKCD 漫画！”。
为什么第一个被认为是辉煌的，而后一个被认为是最致命的罪恶？

#$a=1;
#$b=2;

/* SNIPPET #1 */

try {
    if (!isset($a)) {
      throw new Exception('$a is not set');
    }
    if (!isset($b)) {
      throw new Exception('$b is not set');
    }
    echo '$a + $b = '.($a + $b)."<br>\n";
} catch (Exception $e) {
    echo 'Caught exception: ', $e->getMessage(), "<br>\n";
}

/* SNIPPET #2 */

if (!isset($a)) { 
  $message = '$a is not set';
  goto end;
}
if (!isset($b)) {
  $message = '$b is not set';
  goto end;
}
echo '$a + $b = '.($a + $b)."<br>\n";

end:
if (!empty($message)) {
  echo 'Caught exception: ', $message, "<br>\n";
}

请注意，我知道在制作意大利面条时，投掷功能更加强大且灵活。这对我来说没有什么主要区别。这是使用的问题，而不是概念的问题。

编辑
许多人告诉我，第一个示例应该更新使用。
原因：异常应该仅用于处理错误，而不是实现业务逻辑。
看起来很明智。

因此，停止无用代码执行的唯一方法是 goto （更不用说一些替代品，例如 while、return 等，它们是同样的事情，但更难实现）？

Answer 1

throw/catch 比 goto 灵活得多：您可以从调用抛出异常的代码的函数中捕获。此外，所需的析构函数会自动调用。

Answer 2

我认为你需要反过来问这个问题：当异常完全适合这种情况时，为什么要使用 goto ？这就是例外的原因。

您可能还会问“当我可以轻松使用 goto 时，为什么要使用 while、for 和函数？”

Answer 3

goto 将执行路径硬编码到代码中。另一方面，异常允许在运行时确定执行路径。

例如，假设您有一个在错误时引发异常的数据库类。除了例外情况，您可以捕获该错误，并在呈现错误页面之前执行其他操作（例如清理分配的资源，或者如果您使用非事务性数据库类型，则“回滚”先前的更改。如果您使用 goto，则不会没有机会这样做，因为 goto 会呈现错误页面。

记住，保持代码可重用和灵活是两者的对立面。

Answer 4

在您的示例中，当您检查错误条件并引发异常或在条件失败时调用 goto 时，实际上没有区别。您的示例可以重新编码以消除对任一构造的需要。

异常有用的地方是您调用可能有错误状态但无法自行处理的方法，如以下伪代码所示：

try
{
    $c = add($a, $b);
    echo '$a + $b = '.($c)."<br>\n";
}
catch (Exception $e)
{
    echo 'Caught exception: ', $e->getMessage(), "<br>\n";
}

add 方法执行错误checking：

if (!isset($a))
{
    throw new Exception('$a is not set');
}
if (!isset($b))
{
    throw new Exception('$b is not set');
}

然后返回相加的结果。

这意味着您的主代码流显示了程序的预期路径。

Answer 5

由于还没有人对这个问题提供 OP 认为可以接受的答案，我将投身其中。

…代码结构之间基本的、概念上的区别
以下两个代码片段中的哪一个？

您提供的两个代码片段之间根本没有概念差异。在这两种情况下都会测试条件，如果满足，则会将消息抛出到程序的另一部分进行处理。

为什么第一个被认为是出色的，而后一个被认为是
成为最致命的罪孽？

感谢斯拉普内尔上校为下面的咆哮打开了大门。

<咆哮>

每个编程结构都有被滥用的可能性。对goto的教条式迫害让我想起了对PHP的类似抨击。 PHP 会导致糟糕的编程习惯。 相比：Goto 会导致意大利面条式代码。

简而言之：goto 是“邪恶的”，因为 Edsger Dijkstra 是这么说的尼克劳斯·沃斯 (Niklaus Wirth) 对此表示认可。 ;-p

为了您的阅读乐趣：http://en.wikipedia.org/wiki/Goto

对 GOTO 最著名的批评可能是 Edsger 1968 年的一封信
Dijkstra 称​​Go To statements 被认为是有害的。在那封信中
Dijkstra 认为应该废除不受限制的 GOTO 语句
来自高级语言，因为它们使任务复杂化
分析和验证程序的正确性（特别是
那些涉及循环的）。另一种观点提出于
Donald Knuth 的带有 go to 语句的结构化编程
分析了许多常见的编程任务并发现其中一些
GOTO 是最适合使用的语言结构。

它接着说，

一些程序员，例如Linux内核设计者和编码员Linus
Torvalds 或软件工程师兼书籍作者 Steve McConnell 也
反对 Dijkstra 的观点，指出 GOTO 可能是一个有用的
语言特性，提高程序速度、大小和代码清晰度，
但只有当由一个相对明智的人以明智的方式使用时
程序员。

也就是说，自 Commodore BASIC 以来，我个人还没有发现 GOTO 的实际用途，但这既不存在也不存在。 :-)

Answer 6

goto 非常适合做这样的事情：

foreach ($items as $item) {
    if ($item->is_match()) goto match;
}

$item = new Item();

match:
render('find_item.php', $item);

与此相反：

$matching_item = null;
foreach ($items as $item) {
    if ($item->is_match()) {
        $matching_item = $item;
        break;
    }
}
if ($matching_item === null) {
    $item = new Item();
}

render('find_item.php', $item);

Answer 7

与 throw 相比，goto 可能会有一点性能提升，因为它不会创建任何异常堆栈。

Answer 8

实际上，两个代码段之间的区别在于，您必须花费更多时间使用“goto”代码向其他程序员解释自己。

无论好坏，大多数程序员都认为永远不应该使用 goto。也许你可以证明这是没有根据的，并且你的 goto 代码是实现该功能的最佳方式。即便如此，你也必须与同事或任何与你合作的人进行斗争才能让他们接受它。

如果您自己工作并且没有人会看到您的代码 - 使用您喜欢的任何代码。但如果你在一个团队中工作，有时阻力最小的路径是最谨慎的。

Answer 9

“错误”的是，goto它可以实现多种控制机制，而不仅仅是throw，因此几乎没有固有的结构。因此，脚本程序员对使用 goto 替代方案感兴趣有几个原因：

首先，我们开始看到脚本从纯解释型转向字节码编译型。任何地方都可以找到这样的好例子，例如 Python、Perl 6、Scala (Lift)、Clojure (Compojure)。甚至 PHP 也有字节码编译器。由于 goto 的结构很少，因此无法进行控制机制的编译，这是相当大的性能损失，因为现代编译器通常非常擅长于此。对于抛出，编译器可以开始假设抛出的异常并不常见，因此它通常会以不太理想的“异常”控制路径为代价来优化“正常”控制路径。

即使您没有完整的编译器，当程序员使用具有更多结构的控制机制时，解释器也可以为程序员提供更多帮助。例如，for 循环块由编译器/解释器按词法限定范围，因此程序员可以使用此范围来模块化代码块。否则，使用 goto 您将被迫污染变量名称空间。

此外，如果您的语言允许您声明抛出异常的方法，编译器/解释器可以通知您尚未处理您调用的方法可能遇到的所有可能的异常（类似于< code>throws Java，如果您有这方面的经验）。使用goto，编译器不知道您要做什么，因此它不会在编译和测试期间为您提供帮助。

Goto 还要求程序员从错误中恢复。想象一下，如果您有一些像这样的代码（从您的代码片段中抓取并编辑）：

if (!isset($a)) { 
  $message = '$a is not set';
  goto errorA;
}
if (!isset($b)) {
  $message = '$b is not set';
  goto errorB;
}
if (!moonInRightPhase) {
   goto errorP
}
echo '$a + $b = '.($a + $b)."<br>\n";

errorA:
// Do something non-trivial and unique to handle $a not being set.
goto afterError

errorP:
// Do something non-trivial and unique to handle moon phase
// This error requires drastic failure of code path:
goto failure

errorB:
// Do something non-trivial and unique to handle $b not being set.
goto afterError

afterError:
// Program continues

return SUCCESS

failure:
return FAILURE

这里的问题是程序员需要做正确的事情。如果他忘记goto afterError，他将运行下一个异常路径。使用 throw 机制就不太容易出错。

最后，我的个人经验让我不喜欢 goto 语句，只是因为它不容易阅读。当我试图理解一段带有四个或五个名为 some-error、fail、retry 标签的代码时，它们是不靠近有问题/异常的代码，解开它可能是一场噩梦。如果它不容易阅读，那么即使程序员试图回顾他或她一年前所做的事情也可能会导致错误。

作为这个答案的后记，我不认为“错误”是描述 goto 的正确方式。这可能来自于著名的 Dijkstra 论文的耸人听闻。 “强大”可能是一个更好的术语，因为它意味着它几乎可以做所有事情，但即使是最简单的错误也会使“错误”变成“可怕的错误”。我们不应该禁止工具，因为它们确实很危险；我们应该更好地教育人们了解他们的危险，并让他们做出决定。

Answer 10

我不像很多人那样讨厌 GOTO，但我认为它的主要问题是它不限于特定的“范围”。对于所有其他控制结构，您都知道它从哪里开始和在哪里结束。另一方面，GOTO 标签可能会放置在更难以预测的地方。您当然可以搜索标签，但这会破坏可读性。

当然，一切都取决于它如何使用。

Answer 11

也不要使用。在您想要跳转到末尾的大部分代码和“break”语句周围使用“while(1)”。

while(1)
{
    if (!isset($a)) { 
      $message = '$a is not set';
      break;
    }
    if (!isset($b)) {
      $message = '$b is not set';
      break;
    }

    echo '$a + $b = '.($a + $b)."<br>\n";
    break;
}

if (!empty($message)) {
  echo 'Caught exception: ', $message, "<br>\n";
}