使用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) 更改为检查菜单状态 class 的内容，例如 while (menu.isAlive())。退出就是简单的设置alive属性为false，while循环结束。

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

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

它们在很多方面与 goto 语句相似，因为它们在代码中创建 "invisible" 退出点，逻辑程序流在某些点被打断，这确实会使它变得更复杂在常规调试器中单步执行代码。
使用起来很贵。下面详细介绍。
使代码更难阅读。
是设计问题的征兆，应该加以解决。

我并不是在所有情况下都反对异常，但我不认为所有 "error" 情况的处理都应该使用异常来完成，这取决于 "error" 如何影响程序流程。例如，在错误（抱歉用词不当）确实是异常状态的情况下，它很有意义，例如当套接字死掉时，或者您无法分配新内存时，或类似的事情。在这些情况下，异常是有意义的，特别是因为异常很难被忽略。综上所述在我看来[=44=]异常应该用于特殊情况。

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

关于异常性能的注释，它是如何完成异常处理的具体实现，并且可能因编译器而异。然而，在采取非例外路径时，例外情况通常不会增加额外成本，但在采取例外路径时，有许多报告表明成本确实很高（提到 10 倍/20 倍的成本异常路径上的常规 if）。

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

例如，查看以下通过抛出整数退出的简单代码示例：https://godbolt.org/g/pssysL the global variable is added to prevent the compiler from optimizing the return value out. Compare this to a simple example where the return value is used: https://godbolt.org/g/jMZhT2当采用非异常路径时，异常的成本大致相同，但变得更加昂贵路径被采用。同样，如果异常用于真正的异常情况，这可能没问题，但是当在 "exceptional path" 被更频繁地命中的情况下使用时，成本开始成为一个因素。

使用throws来控制程序流程？

Using throws to control program flow?

c++

throw

program-flow