使用 throws 来控制程序流程？

Question

程序通过class Menu与用户通信，所以main()是这样的：

int main() {
    try {
        Menu menu(/*...*/);
        while (true) {
            menu.printOptions();
            menu.chooseOption();
        }
    }
    catch (const char *error) { /*Resolve error.*/ }
    catch (int code) { /*Exit with code.*/ }
}

当前class Menu用于退出的选项如下：

void exit() {
    // Release memory.
    throw 0;
}

应该避免这样的构造吗？它们是否有一些不可预测（或不希望的）副作用？

Answer 1

我会避免使用异常作为以这种方式控制流程的手段。相反，您可以将循环从while (true) 更改为检查菜单类状态的内容，例如while (menu.isAlive())。退出只是简单地将alive属性设置为false，这将结束while循环。

异常应该用于当前流无法恢复的情况，并且需要您将控制权返回给父流。话虽如此，没有什么可以阻止您以这种方式使用异常，但是我个人认为为错误处理设置异常已经足够糟糕了，因此隐藏了跳转，但让它们用于常规流程控制，绝对是我认为污染代码的东西，并使其难以预测。

异常有很多其他关于反模式的文章中也会发现的问题，即：

• 它们在很多方面与goto 语句相似，因为它们在代码中创建了“不可见”的退出点，逻辑程序流程在某些点被中断，这确实会使单步执行代码变得更加复杂常规调试器。
• 使用起来很昂贵。详情请参阅下文。
• 使代码更难阅读。
• 是设计问题的症状，应该予以解决。

我并不是在所有情况下都反对异常，但我不认为所有“错误”情况的处理都应该使用异常来完成，这取决于“错误”如何影响程序流程。例如，在错误（对不起，措辞不好）确实是异常状态的情况下，例如当套接字死亡，或者您无法分配新内存或类似情况时，它非常有意义。在这些情况下，异常是有意义的，尤其是因为异常很难被忽略。总之在我看来例外情况应该用于例外情况。

在 SO 和您可能感兴趣的其他 Stack Exchange 网站上还有其他解决此问题的答案：
Are exceptions as control flow considered a serious antipattern? If so, Why?
Why not use exceptions as regular flow of control?

---

关于异常性能的说明，它是特定于实现的异常处理方式，并且可能因编译器而异。然而，在采用非异常路径时，异常通常不会增加额外成本，但在采用异常路径时，有许多报告表明成本确实很高（https://stackoverflow.com/a/13836329/111143 提到成本是常规 @ 的 10 倍/20 倍987654331@ 在异常路径上）。

由于异常的实现特定于编译器，因此很难对此给出任何一般性的答案。但是检查编译器生成的代码可能会显示使用异常时添加的内容。例如，在捕获异常时，您需要抛出异常的类型信息，这为抛出异常增加了额外的成本。当您真正面临一个应该很少发生的异常状态时，这种额外的成本几乎没有什么区别。但如果用于控制常规程序流程，则成本高昂。

例如看下面一个通过抛出一个整数退出的简单代码示例：https://godbolt.org/g/pssysL 添加了全局变量以防止编译器优化返回值。将此与使用返回值的简单示例进行比较：https://godbolt.org/g/jMZhT2 当采用非异常路径时，异常的成本大致相同，但采用异常路径时成本会更高。同样，如果将异常用于真正的异常情况，这也可以，但在“异常路径”被更频繁地命中的情况下使用时，成本开始成为一个因素。