当将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了(是的，如果您稍后调用一个可能抛出的函数，这就有问题了)。