为什么异常规范不好？

大约10年前回到学校时，他们正在教您使用异常说明符。由于我的背景是其中的一位Torvaldish C程序员，他们顽固地避免使用C ++（除非被迫这么做），所以我只会偶尔散布C ++，并且当我这样做时，我仍然使用异常说明符，因为这就是我所教的。

但是，大多数C ++程序员似乎并不喜欢异常说明符。我已经阅读了各种C ++专家的辩论和论点，例如这些。据我了解，它可以归结为三点：

1. 异常说明符使用与其余语言不一致的类型系统（“影子类型系统”）。
2. 如果您的带有异常说明符的函数抛出了除您指定的内容以外的其他任何内容，则该程序将以不良的意外方式终止。
3. 即将在即将发布的C ++标准中删除异常说明符。

我在这里错过什么还是所有这些原因吗？

我个人的意见：

关于1）：那又如何。就语法而言，C ++可能是有史以来最不一致的编程语言。我们有宏，goto /标签，未定义/未指定/实现定义的行为的部落（ho？），定义欠佳的整数类型，所有隐式类型升级规则，特殊情况下的关键字，例如friend，auto ，注册，显式...等等。有人可能会写几本关于C / C ++怪异故事的厚书。那么，人们为什么要对这种特殊的矛盾做出反应呢？与语言的许多其他更危险的特征相比，这是一个较小的缺陷？

关于2）：这不是我的责任吗？我可以用C ++编写致命错误的方法有很多，为什么这种特殊情况会更糟？除了编写throw(int)然后抛出Crash_t之外，我还可以声明我的函数返回一个指向int的指针，然后进行一个狂野的，显式的类型转换，然后返回一个指向Crash_t的指针。C / C ++的精神始终是将大部分责任留给程序员。

那优势呢？最明显的是，如果您的函数尝试显式抛出除指定类型之外的任何类型，则编译器将给您一个错误。我认为有关此标准很明确。仅当您的函数调用其他函数而又抛出错误的类型时，才会发生错误。

来自确定性的嵌入式C程序世界，我当然希望更确切地知道函数会给我带来什么。如果有某种语言支持该功能，为什么不使用它呢？替代方案似乎是：

void func() throw(Egg_t);

和

void func(); // This function throws an Egg_t

我认为在第二种情况下，调用者有很大的机会忽略/忘记实现try-catch，而在第一种情况下则更少。

据我了解，如果这两种形式之一决定突然引发另一种异常，则程序将崩溃。在第一种情况下，因为不允许它抛出另一个异常，在第二种情况下，因为没有人期望它抛出SpanishInquisition_t，因此该表达式不会在应有的位置被捕获。

如果是后者，在程序的最高级别进行一些最后的捕获似乎并没有比程序崩溃更好的方法：“嘿，程序中的某处引发了一个奇怪的，未处理的异常”。一旦远离异常引发的地方，您将无法恢复程序，唯一可以做的就是退出程序。

从用户的角度来看，如果他们从操作系统中收到一个错误消息框，说“程序终止。地址为0x12345的Blablabla”，或者从您的程序中获得一个错误消息框，指出了“未处理的异常：myclass。 func.something”。该错误仍然存​​在。

随着即将到来的C ++标准，我将别无选择，只能放弃异常说明符。但是，我宁愿听到一些可靠的论据，说明它们为什么不好，而不是“圣洁已经说过了，事实就是如此”。也许对他们的争论比我列出的要多，或者对他们的争论比我所意识到的还要多？

异常规范是不好的，因为它们的执行力很弱，因此实际上执行不了什么，它们也很糟糕，因为它们强制运行时检查意外的异常，以便可以终止（），而不是调用UB。 ，这会浪费大量性能。

因此，总而言之，异常规范在语言中的执行程度不足以使代码实际上变得更安全，因此按规定实施它们会浪费大量性能。

没有人使用它们的原因之一是因为您的主要假设是错误的：

“最明显的优势是，如果您的函数试图显式抛出除指定类型之外的任何类型，则编译器将给您一个错误。”

struct foo {};
struct bar {};

struct test
{
    void baz() throw(foo)
    {
        throw bar();
    }
};

int main()
{
    test x;
    try { x.baz(); } catch(bar &b) {}
}

该程序的编译没有错误或警告。

此外，即使将捕获异常，程序仍会终止。

编辑：要回答您问题的一个要点，即使您不这样做，catch（...）（或更好的是catch（std :: exeption＆）或其他基类，然后 catch（...））仍然有用确切知道出了什么问题。

考虑到您的用户点击了“保存”菜单按钮。菜单按钮的处理程序邀请应用程序保存。由于种种原因，该操作可能会失败：该文件位于网络资源上消失了，有一个只读文件，无法保存，等等。它只关心成功还是失败。如果成功，一切都很好。如果失败，它可以告诉用户。异常的确切性质无关紧要。此外，如果您编写正确的，异常安全的代码，则意味着任何此类错误都可以在您的系统中传播而不会降低它-即使对于不关心该错误的代码也是如此。这使扩展系统变得更加容易。例如，您现在通过数据库连接进行保存。

对安德斯·海斯伯格的采访非常有名。在其中，他解释了为什么C＃设计团队首先丢弃已检查的异常。简而言之，有两个主要原因：可版本性和可伸缩性。

我知道OP专注于C ++，而Hejlsberg正在讨论C＃，但是Hejlsberg提出的观点也完全适用于C ++。