在函数签名中使用c++ throw关键字被认为是坏习惯的技术原因是什么?

bool some_func() throw(myExc)
{
  ...
  if (problem_occurred) 
  {
    throw myExc("problem occurred");
  }
  ...
}

当前回答

当将throw规范添加到语言中时,它是出于最好的意图,但实践证明了一种更实用的方法。

在c++中,我的一般经验法则是只使用抛出规范来指示一个方法不能抛出。这是一个强有力的保证。否则,假设它可以抛出任何东西。

其他回答

不,这被认为是不好的做法。相反,它通常被认为是一个坏主意。

http://www.gotw.ca/publications/mill22.htm详细介绍了原因,但问题部分在于编译器无法强制执行,因此必须在运行时进行检查,这通常是不可取的。而且它在任何情况下都没有得到很好的支持。(MSVC忽略异常规范,但throw()除外,它将其解释为保证不会抛出异常。

当将throw规范添加到语言中时,它是出于最好的意图,但实践证明了一种更实用的方法。

在c++中,我的一般经验法则是只使用抛出规范来指示一个方法不能抛出。这是一个强有力的保证。否则,假设它可以抛出任何东西。

抛出说明符的唯一实际效果是,如果你的函数抛出了与myExc不同的东西,std::unexpected将被调用(而不是正常的未处理异常机制)。

为了记录函数可以抛出的异常类型,我通常这样做:

bool
some_func() /* throw (myExc) */ {
}

Jalf已经链接到它了,但是GOTW很好地解释了为什么异常规范没有人们希望的那么有用:

int Gunc() throw();    // will throw nothing (?)
int Hunc() throw(A,B); // can only throw A or B (?)

这些评论正确吗?不完全是。Gunc()可能确实会扔东西,而Hunc()很可能会扔A或B以外的东西!如果它们这样做,编译器只会保证把它们打得毫无意义……哦,大多数情况下,也会把你的程序打得毫无意义。

这就是最终的结果,您可能只会调用terminate(),并且您的程序会快速但痛苦地死亡。

GOTWs的结论是:

因此,以下似乎是我们作为一个社区到目前为止学到的最好的建议: 寓意#1:永远不要编写异常规范。 寓意2:可能除了一个空的,但如果我是你,我甚至会避免这样做。

好吧,当谷歌关于这个抛出规范,我有一看这篇文章:- (http://blogs.msdn.com/b/larryosterman/archive/2006/03/22/558390.aspx)

我在这里也复制了它的一部分,这样它就可以在未来使用,不管上面的链接是否有效。

   class MyClass
   {
    size_t CalculateFoo()
    {
        :
        :
    };
    size_t MethodThatCannotThrow() throw()
    {
        return 100;
    };
    void ExampleMethod()
    {
        size_t foo, bar;
        try
        {
            foo = CalculateFoo();
            bar = foo * 100;
            MethodThatCannotThrow();
            printf("bar is %d", bar);
        }
        catch (...)
        {
        }
    }
};

当编译器看到这一点时,使用"throw()"属性,编译器可以完全优化"bar"变量,因为它知道没有办法从MethodThatCannotThrow()抛出异常。如果没有throw()属性,编译器必须创建“bar”变量,因为如果MethodThatCannotThrow抛出异常,异常处理程序可能/将依赖于bar变量的值。

此外,像prefast这样的源代码分析工具可以(也将)使用throw()注释来提高它们的错误检测能力——例如,如果您有一个try/catch,并且您调用的所有函数都标记为throw(),那么您就不需要try/catch了(是的,如果您稍后调用一个可能抛出的函数,这就有问题了)。