3

我已经阅读了很多关于（不）throw(X)在函数签名中使用的论点，我认为它在 ISO C++ 中指定的方式（并在当前编译器中实现）是相当没用的。但是为什么编译器不能简单地在编译时强制执行异常正确性呢？

如果我编写包含throw(A,B,C)在其签名中的函数/方法定义，编译器在确定给定函数的实现是否异常正确时应该不会有很多问题。这意味着函数体有

  • 除了;没有throw其他的throw A; throw B; throw C;
  • 没有任何函数/方法调用的 throw-signatures 限制小于throw (A,B,C);

，至少在try{}catch()捕捉其他抛出类型之外。如果编译器在不满足这些要求的情况下引发错误，则所有函数都应该是“安全的”，并且不需要运行时函数unexpected()。所有这些都将在编译时得到保证。

void fooA() throw (A){
}

void fooAB() throw (A,B){
}

void fooABC() throw (A,B,C){
}


void bar() throw (A){

    throw A();   // ok
    throw B();   // Compiler error

    fooA();      // ok
    fooAB();     // compiler error
    fooABC();    // compiler error

    try{
       throw A();   // ok
       throw B();   // ok
       throw C();   // Compiler error

       fooA();   // ok
       fooAB();  // ok
       fooABC(); // compiler error
    } catch (B){}
}

throw()这将要求默认指定所有非 C++ 领域代码（默认情况下extern "C"应假定它），或者如果存在一些异常互操作性，则还应指定适当的标头（至少对于 C++）throw。不这样做可以与在不同的编译单元中使用具有不同函数/方法返回类型的头文件进行比较。虽然它没有产生警告或错误，但它显然是错误的 - 由于抛出的异常是签名的一部分，它们也应该匹配。

如果我们强制执行这样的约束，它将产生三个影响：

  • 它将删除所有那些隐式try{}catch块，否则运行时检查需要，从而提高异常处理性能。
  • “异常使我们的库太大，所以我们关闭它们”的论点；会消失，因为大多数附加代码都存在于每个函数调用中那些不必要的隐式 throw/catch 指令中。如果代码被正确throw指定，大部分代码都不会被编译器添加。
  • 这会让编程界的大多数人大发雷霆，因为似乎没有人喜欢例外。现在，由于这些实际上是可用的，我们需要学习如何使用它们。

如果我们对旧代码使用一些兼容性编译器标志，它不会破坏任何东西，但是由于新的异常代码会更快，所以不使用它编写新代码是一个很好的动机。

总结一下我的问题：为什么 ISO C++ 不需要这种强制措施？有什么强有力的理由让它不存在吗？我一直认为异常只是另一个函数的返回值，但它是自动管理的，所以你可以避免编写类似的函数

std::pair<int, bool> str2int(std::string s);
int str2int(std::string s, bool* ok);

加上额外的变量自动销毁和通过堆栈上的多个函数传播，所以你不需要像这样的代码

int doThis(){

    int err=0;

    [...]

    if ((err = doThat())){
        return err;
    }

    [...]

}

;如果你可以return只要求正确类型的功能，为什么你不能要求它throw呢？

为什么异常说明符不能更好？为什么它们不像我从一开始就描述的那样制作？

PS 我知道例外和模板可能存在一些问题——取决于这个问题的答案，也许我会问另一个问题——现在让我们忘记模板。

编辑（回应@NicolBolas）：

编译器可以对异常类 X 做什么样的优化，而对 Y 却做不到呢？

相比：

void fooA() throw (A){
}

void fooAB() throw (A,B){
}

void fooABC() throw (A,B,C){
}


void bar() throw (){

    try{
       fooA();
         // if (exception == A) goto A_catch
       fooAB();
         // if (exception == A) goto A_catch
         // if (exception == B) goto B_catch
       fooABC();
         // if (exception == A) goto A_catch
         // if (exception == B) goto B_catch
         // if (exception == C) goto C_catch
    }
    catch (A){  // :A_catch
      [...]
    }
    catch (B){  // :B_catch
      [...]
    }
    catch (C){  // :C_catch
      [...]
    }
}

和：

void fooA(){
}

void fooAB(){
}

void fooABC(){
}


void bar(){

    try{
       fooA();
         // if (exception == A) goto A_catch;
         // if (exception == B) goto B_catch;
         // if (exception == C) goto C_catch;
         // if (exception == other) return exception;
       fooAB();
         // if (exception == A) goto A_catch;
         // if (exception == B) goto B_catch;
         // if (exception == C) goto C_catch;
         // if (exception == other) return exception;
       fooABC();
         // if (exception == A) goto A_catch;
         // if (exception == B) goto B_catch;
         // if (exception == C) goto C_catch;
         // if (exception == other) return exception;
    }
    catch (A){  // :A_catch
      [...]
    }
    catch (B){  // :B_catch
      [...]
    }
    catch (C){  // :C_catch
      [...]
    }
}

在这里，我包含了一些编译器不会生成汇编级别的伪代码。如您所见，知道您可以获得哪些异常可以减少代码量。如果我们在这里有一些额外的变量要销毁，额外的代码会更长。

4

3 回答 3

5

作为函数签名的一部分的编译器验证异常有两个（理论上的）优点：编译器优化和编译时错误检查。

X就编译器而言，抛出异常的函数 class和 class有什么区别Y？最终……什么都没有。X编译器可以对它不能做的异常类做什么样的优化Y？除非std::exception是特殊的（并且X是从它派生的，而Y不是），对编译器有什么影响？

最终，编译器在优化方面唯一关心的是函数是否会抛出任何异常。这就是 C++11 标准委员会放弃throw(...)支持的原因noexcept，它声明该函数不会抛出任何东西。

至于编译时错误检查，Java 清楚地展示了它的工作原理。您正在编写一个函数，foo. 你的设计有它抛出X和Y。其他代码片段使用foo，并且他们抛出任何foo抛出的东西。但是异常规范并没有说“无论foo抛出什么”。它必须列出X并Y具体。

现在您返回并进行更改foo，使其不再抛出X，但现在它会抛出Z。突然，整个项目停止编译。您现在必须转到每个抛出任何foo抛出的函数，以将其异常规范更改为 match foo。

最终，程序员只是举手并说它会抛出任何异常。当您放弃这样的功能时，实际上是在承认该功能弊大于利。

并不是说它们没有用。只是它们的实际使用表明它们通常没有用。所以没有意义。

另外，请记住，C++ 的规范声明没有规范意味着将抛出任何东西，而不是什么都不会（如在 Java 中）。使用该语言的最简单方法就是这样：不检查。所以会有很多人不想使用它。

许多人不想打扰的功能有什么好处，即使是那些喜欢的人通常也会因此而感到悲伤？

于 2012-07-05T23:52:51.203 回答
1

这意味着函数体有

除了投掷A之外没有投掷；扔B；投掷 C;;
没有比 throw (A,B,C) 更严格的 throw 签名的函数/方法调用；

不要忘记代码可以在不同的时间在不同的机器上编译，并且只能在运行时通过动态库链接在一起。编译器可能具有被调用函数签名的本地版本，但它可能与运行时实际使用的版本不匹配。（我认为如果异常不完全匹配，我认为可以修改链接器以禁止链接，但这可能会带来比它解决的更多的烦恼。）

于 2012-07-05T22:34:48.663 回答
0

在某些情况下，抛出规范可能很有用，尤其是在嵌入式系统上，其中的替代方法是完全禁止异常。除此之外，如果唯一允许抛出的函数是那些明确指定的函数，那么在调用不能抛出的函数时可以消除异常处理开销。请注意，即使在使用“元数据”进行异常处理的系统中，异常处理程序必须能够理解堆栈帧这一事实排除了原本可能实现的优化。

抛出规范可能有用的另一种情况是，如果编译器允许catch语句指定它们应该只捕获没有通过任何非“预期”层冒泡的异常。C++ 中异常处理概念和借用它的语言的一个主要弱点是，对于由此记录的条件，没有很好的方法来区分发生在被调用例程中的异常与发生在嵌套子例程中的异常，例如直接调用例程的原因没想到。如果一个catch声明可以作用于前者而不捕捉后者，那将是有帮助的。

于 2012-07-05T23:57:25.677 回答