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

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

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

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

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

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

对于只返回成员变量且不可能抛出异常的内联函数的no throw规范可能被某些编译器用于执行悲观化(优化的反义词)，这可能会对性能产生不利影响。这在Boost文献中有描述:异常规范

对于一些编译器，如果进行了正确的优化，并且该函数的使用以一种合理的方式影响性能，那么非内联函数的无抛出规范可能是有益的。

对我来说，是否使用它听起来像是一个由非常挑剔的眼睛做出的决定，作为性能优化工作的一部分，可能会使用分析工具。

对于那些赶时间的人，引用以上链接(包含一个简单编译器在内联函数上指定throw的不良意外影响的示例):

Exception-specification rationale Exception specifications [ISO 15.4] are sometimes coded to indicate what exceptions may be thrown, or because the programmer hopes they will improve performance. But consider the following member from a smart pointer: T& operator*() const throw() { return *ptr; } This function calls no other functions; it only manipulates fundamental data types like pointers Therefore, no runtime behavior of the exception-specification can ever be invoked. The function is completely exposed to the compiler; indeed it is declared inline Therefore, a smart compiler can easily deduce that the functions are incapable of throwing exceptions, and make the same optimizations it would have made based on the empty exception-specification. A "dumb" compiler, however, may make all kinds of pessimizations. For example, some compilers turn off inlining if there is an exception-specification. Some compilers add try/catch blocks. Such pessimizations can be a performance disaster which makes the code unusable in practical applications. Although initially appealing, an exception-specification tends to have consequences that require very careful thought to understand. The biggest problem with exception-specifications is that programmers use them as though they have the effect the programmer would like, instead of the effect they actually have. A non-inline function is the one place a "throws nothing" exception-specification may have some benefit with some compilers.

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

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

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

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

为了给这个问题的其他答案增加一点价值，你应该在这个问题上花几分钟: 下面代码的输出是什么?

#include <iostream>
void throw_exception() throw(const char *)
{
    throw 10;
}
void my_unexpected(){
    std::cout << "well - this was unexpected" << std::endl;
}
int main(int argc, char **argv){
    std::set_unexpected(my_unexpected);
    try{
        throw_exception();
    }catch(int x){
        std::cout << "catch int: " << x << std::endl;
    }catch(...){
        std::cout << "catch ..." << std::endl;
    }
}

答:正如这里所指出的，程序调用std::terminate()，因此不会调用任何异常处理程序。

详细信息:第一个my_unexpected()函数被调用，但由于它不会为throw_exception()函数原型重新抛出匹配的异常类型，因此最后调用std::terminate()。所以完整的输出是这样的:

user@user:~/tmp$ g++ -o except。测试except.test.cpp user@user: ~。美元/ tmp / except.test 嗯——这是出乎意料的 抛出'int'实例后调用的终止 中止(核心转储)