0

程序通过 与用户通信，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.*/ }
}

Currentclass Menu用于退出的选项如下：

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

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

4

1 回答 1

1

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

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

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

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

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

在 SO 和其他 Stack Exchange 站点上还有其他答案可以解决您可能感兴趣的问题：
作为控制流的异常是否被认为是一种严重的反模式？如果是这样，为什么？
为什么不使用异常作为常规控制流？

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

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

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

于 2016-11-29T11:25:04.957 回答